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  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:	Sat, 22 Nov 2008 21:29:07 -0600
From:	Eric Sandeen <>
To:	Andreas Dilger <>
CC:	ext4 development <>
Subject: Re: [PATCH] e2fsck: ignore differing NEEDS_RECOVERY flag on backup

Andreas Dilger wrote:
> On Nov 22, 2008  09:02 -0600, Eric Sandeen wrote:
>> This is for RH bugzilla 471925 -  Complete scan of filesystems expanded online
>> When we resize online, the primary superblock gets copied to all
>> the backups, and of course since we're mounted the NEEDS_RECOVERY
>> flag is set.  A subsequent fsck will find the backups have the
>> NEEDS_RECOVERY flag set while the primary does not, and this
>> forces a full fsck pass.
>> I think this flag can be safely ignored in the flag comparisons.
> Should we also mask out this flag from the backup superblock copies
> when they are made, or is there an equal chance that the superblock
> has NEEDS_RECOVERY and the backups do not?

I think it might be a good idea (to mask at growfs time) for
completeness.  Is there *ever* any valid reason for a backup superblock
to have this flag set?  Near as I can tell, online growfs is the only
thing that ever sets it, and this "flag match" check is the only thing
that ever tests it.

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists