linux-ext4 - Re: Ininitial e2fsprogs TODO list (please expand)

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]

Message-id: <20080417032652.GD3473@webber.adilger.int>
Date:	Wed, 16 Apr 2008 21:26:52 -0600
From:	Andreas Dilger <adilger@....com>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Ininitial e2fsprogs TODO list (please expand)

On Apr 15, 2008  23:35 -0500, Jose R. Santos wrote:
> On Tue, 15 Apr 2008 21:30:02 -0600
> Andreas Dilger <adilger@....com> wrote:
> > Something was lost in translation here.  The uninit_groups feature DOES
> > zero the inode tables by default, and marks the groups with ITABLE_ZEROED.
> > It is only if "-O uninit_groups,lazy_bg" are both given at the same time
> > that the itable is not initialized.  That is no different than if lazy_bg
> > was given by itself.
> 
> Yes, I understand this part.
>  
> > So nothing needs to be done in e2fsprogs until some time after the kernel
> > is updated to do the zeroing.
> 
> The problem is that not initializing the inode table on the uninit
> block group patch depends on a feature (lazy_bg) that Ted wants
> removed.  I believe that just removing the lazy_bg feature would be
> enough to remove this capability from the uninit patch, but was not
> entirely sure so I put the item just to keep track of it.
> 
> If lazy_bg is in fact removed from e2fsprogs, I suppose we need to add
> another item to enable lazy setup of the inode tables once the proper
> support in the kernel is establish.

Yes, the "lazy init" for uinint_groups will essentially be identical to
what we have in lazy_bg today.  So if we are disabling lazy_bg as a
user-selectable option, we should leave the code in place for later use.
I wouldn't object to requiring a user to specify "mke2fs -O FEATURE_C6"
to enable it.  That keeps it out of the hands of newbies, but leaves the
capability to test large filesystems w/o 45 minute mke2fs times.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
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