linux-ext4 - Re: E2fsprogs master branch now has all 64-bit patch applied

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jun 2010 10:46:42 -0400
From:	Ric Wheeler <rwheeler@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	linux-ext4@...r.kernel.org
Subject: Re: E2fsprogs master branch now has all 64-bit patch applied

On 06/14/2010 09:39 AM, Theodore Ts'o wrote:
> It's taken way too long, but I've finally finished integrating the
> 64-bit patches into e2fsprogs's mainline repository.  All of the
> necessary patches should now be in the master branch for e2fsprogs.
>
> The big change from before is that I replaced Val's changes for fixing
> up how mke2fs picked the correct fs-type profile from mke2fs.conf with
> something that I think works much better and leaves the code much
> cleaner.  With this change you need to add the following to your
> /etc/mke2fs.conf file if you want to enable the 64-bit feature flag
> automatically for a big disk:
>
> [fs_types]
> 	ext4 = {
> 		features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
> 		auto_64-bit_support = 1   #<---- add this line
> 		inode_size = 256
> 	}
>
> Alternatively you can change the features line to include the feature
> "64bit"; this will force the use of the 64-bit fields, and double the
> size of the block group descriptors, even for smaller file systems that
> don't require the 64-bit support.  (This was one of my problems with
> Val's implementation; it forced the mke2fs.conf file to always enable
> the 64-bit feature flag, which would cause backwards compatibility
> issues.)  This might be a good thing to do for debugging purposes,
> though, so this is an option which I left open, but the better way of
> doing things is to use the auto_64-bit-support flag.
>
> Should the default for auto_64-bit-support be on or off?  For now I've
> left it to be defaulted to "off", on the theory that it might be useful
> for distributions that aren't quite ready to enable 64-bit support until
> we do a lot more testing.  But I may very well change this default
> before 1.42 ships, on the theory that people who want to disable this
> just ship an edited mke2fs.conf file.  (Users can always explicit
> request 64bit support by using "mke2fs -O 64bit", of course.)  Comments
> on this would be appreciated.
>
> The other support which I've added into mke2fs.conf handling is I've
> added two additional automatically selected fs-types, which work like
> "floppy" and "small".  These are "big" which is automatically selected
> for filesystems>= 4TB, and and "huge" which is elected for filesystems
>    
>> = 16TB.  I'm not 100% sure this will be useful, but it seemed like
>>      
> it might be useful to have these.  Again, comments appreciated it; the
> names and the cutoff points may change before the 1.42 release.
>
> What are things that are still left to be done before we 64-bit support
> is completely supported?  Just a few things:
>
> * Currently the badblocks list mechanism only supports 32-bit blocks.
>    This may be OK, since running "badblocks" on a really large disk is
>    probably a fool's errand.  But how we handle this is an open question;
>    should we just refuse "mke2fs -c" or "e2fsck -c" for really big file
>    systems?  Should we deprecate the badblocks inode altogether?
>    

I think that badblocks is pretty much a legacy item at this point. 
Certainly not common on really large devices which are almost always 
RAID'ed in some form.

Thanks!

Ric

> * The online resizing code, which relies on using a resize inode and
>    indirect blocks, will not scale to 64-bit filesystems.  We have the
>    beginnings of support for the "meta_bg" style of resizing, which is
>    supported by the kernel and the e2fsprogs code --- but it hasn't been
>    implemented in the kernel yet.  We need to add that.
>
>    As a related note, currently the online resizing code doesn't
>    understand about flex_bg, so the filesystem layout for filesystems
>    which are grown using online resizing is definitely not optimized for
>    flex_bg.  This is something that we would probably want to fix at the
>    same time, since it means adding a new ioctl interface between the
>    kernel and the resize2fs program.
>
> 							- Ted
>    
--
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