linux-ext4 - Re: [PATCH] e2fsck: ignore differing NEEDS

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]

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