| 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
| ||
|
Message-ID: <4928CE03.8010003@redhat.com> Date: Sat, 22 Nov 2008 21:29:07 -0600 From: Eric Sandeen <sandeen@...hat.com> To: Andreas Dilger <adilger@....com> CC: ext4 development <linux-ext4@...r.kernel.org> Subject: Re: [PATCH] e2fsck: ignore differing NEEDS_RECOVERY flag on backup sbs 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. -Eric -- 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