linux-ext4 - Re: Corruption from interrupted e2fsck

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151103160055.GB6729@thunk.org>
Date:	Tue, 3 Nov 2015 11:00:55 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Corruption from interrupted e2fsck

On Mon, Nov 02, 2015 at 02:31:01PM -0700, Andreas Dilger wrote:
> > You're right.  My suggested fix would be in the case of
> > E2F_FLAG_CANCEL, we set the ctx->invalid_bitmaps flag, and then avoid
> > writing out the quota file if invalid_bitmaps is enabled.
> 
> I was looking at that too.  In some sense it isn't a bad idea to allow
> updating the quota file in this case, but it still bothers me that e2fsck
> would continue on to update the quotas if the user wants to kill it, so
> my preference would be to not write the quota files at all if e2fsck is
> interrupted.

I agree; that's why I suggested that if E2F_FLAG_CANCEL was set, then
we would skip wrting out the quota file.

> It would probably make more sense to have an option like "-E quota-only"
> to allow running a shorter e2fsck (maybe useful for link-farm backups
> that take a long time in later passes) but most of the time pass 1 is
> the slowest so there is usually minimal benefit from skipping later passes.

This is a separate issue.  One of the reasons why I wanted to
integrate the quota checking into e2fsck is that since quota tracking
is *always* enabled if the quota inode(s) are present.  So the only
time the quota should be inconsistent (and so when we would need to
update the quota file) is if the file system itself had gotten
inconsistent, since the quota file is now considered *part* of the
file system metadata that should always be consistence in the absense
of a kernel bug, hardware-induced corruption, or someone messing with
the file system out of band using something like debugfs.

Cheers,

					- 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