> On Nov 2, 2015, at 8:23 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Sun, Nov 01, 2015 at 06:16:50PM -0700, Andreas Dilger wrote: >> Is there a reason not to have a cancel check right after the return from >> e2fsck_run() rather than trying to recover the journal and quota files? >> I can imagine that there is a desire to flush out modified inodes and such >> that have been repaired, so that restarting an interrupted e2fsck will make >> progress, but the quota file update is plain wrong unless at least pass1 >> has finished, and the journal recreation is also dangerous if the block >> bitmaps have not been fully updated. > > 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. 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. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
