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  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:	Thu, 13 Nov 2008 15:30:57 -0500
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4@...r.kernel.org,
	Valerie Aurora Henson <vaurora@...hat.com>
Subject: Re: [RFC,PATCH] 64-bit support for e2fsprogs

On Wed, Nov 12, 2008 at 01:25:38PM -0700, Andreas Dilger wrote:
> On Nov 11, 2008  19:42 -0800, Valerie Aurora Henson wrote:
> > Use the following mke2fs command to produce a file system with more
> > than 2^32 blocks:
> > 
> > $ mke2fs -t ext4 -O 64bit -b 4096 -N 200000 <device>
> 
> Ted, this actually exposes a bug in mke2fs, in that the device size to
> "type" detection code is broken.  Val was reporting that running on a
> 16TB device would pick the "floppy" type and try to use 1024-byte blocks
> and 1 inode per 1024 bytes, which would exceed the 2^32 inode limit.
> Hence the current requirement to specify a 4096-byte blocksize and a
> hard limit on the number of inodes.

16TB using a 4k block size is 2**32 blocks, so it's not surprising
it's screwing up and picking the floppy type.  I assume it's only
looking at fs_param->s_blocks_count and not fs_param->s_blocks_count_hi.

It also needs to cap the number of inodes in case of very large
filesystems to make sure we don't overflow 2**32 inodes, yes.

I'm not sure I would call this a bug in the existing mke2fs code, as
much as it is simply that the 64-bit support is not yet complete.  Or
am I missing something in what you complaining about?

						- 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

Powered by blists - more mailing lists