lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 25 Oct 2016 19:05:21 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Eric Whitney <enwlinux@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: allow inode expansion for nojournal file systems

On Tue, Oct 25, 2016 at 03:54:16PM -0600, Andreas Dilger wrote:
> I think the reason we required that the filesystem be journaled to expand
> the inode reserved space is to ensure that the update was an all-or-nothing
> approach.  If there are in-inode xattrs that need to be moved to an external
> xattr block, and that block needs allocation and such, it is possible that
> a nojournal filesystem could result in the xattrs being moved and the inode
> is written (w/o the xattrs), but the xattr block is not written to disk
> before a crash.

In nojournal mode, any number of failures can cause data loss.  For
example, we could be splitting a node in an extent tree, or in a htree
directory block, and we can end up losing data if we crash at an
inconvenient time.  The chances of losing half of an interior node of
an extent tree block after a crash is going to be the same, and the
data loss form such same is going to be far worse than the loss if we
are unluck expanding an inode and moving xattrs to an external block....

    	   	     	      	  - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists