On Thu, Nov 13, 2008 at 03:30:57PM -0500, Theodore Tso wrote: > 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. Actually, the main reason I hard-code the inodes is to speed up file system creation time. > 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? I haven't tracked down the cause of this yet but I suspect it is overflow as well. -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
