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

Powered by blists - more mailing lists