linux-ext4 - Re: [PATCH] ext4: allow inode expansion for nojournal file systems

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]

Message-ID: <20161025230521.dut6yubmg3gpf4d5@thunk.org>
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