From: Valerie Aurora Henson <vaurora@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@sun.com>, linux-ext4@vger.kernel.org
Subject: Re: [RFC,PATCH] 64-bit support for e2fsprogs
Date: Thu, 13 Nov 2008 22:01:33 -0500 [thread overview]
Message-ID: <20081114030133.GG20637@shell> (raw)
In-Reply-To: <20081113203057.GD21652@mit.edu>
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
prev parent reply other threads:[~2008-11-14 3:01 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 3:42 [RFC,PATCH] 64-bit support for e2fsprogs Valerie Aurora Henson
2008-11-12 3:42 ` [RFC PATCH 01/17] Disable tst_refcount - doesn't compile, don't know why Valerie Aurora Henson
2008-11-12 3:42 ` [RFC PATCH 02/17] Squash warnings Valerie Aurora Henson
2008-11-12 3:42 ` [RFC PATCH 03/17] Add 64-bit bitops Valerie Aurora Henson
2008-11-12 3:42 ` [RFC PATCH 04/17] Implement 64-bit "bitarray" bmap ops Valerie Aurora Henson
2008-11-12 3:42 ` [RFC PATCH 05/17] Convert libext2fs to 64-bit bitmap interface Valerie Aurora Henson
2008-11-12 3:42 ` [RFC PATCH 06/17] Convert mke2fs to new " Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 07/17] Convert e2fsck " Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 08/17] Turn on new bitmaps in e2fsck and mke2fs Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 09/17] Add progress bar for allocating block tables - takes forever on large Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 10/17] signed int -> blk64_t to fix bugs at 2^31 - 2^32 blocks Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 11/17] Fix overflow in calculation of total file system blocks Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 12/17] Add ext2fs_block_iterate3 (from Ted) Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 13/17] Support 48-bit file acl blocks Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 14/17] super->s_*_blocks_count -> ext2fs_*_blocks_count() Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 15/17] Convert to inode/block/bitmap/table loc()/loc_set() functions Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 16/17] ext2fs_block_alloc_stats -> ext2fs_block_alloc_stats2 Valerie Aurora Henson
2008-11-12 3:43 ` [RFC PATCH 17/17] Convert to 64-bit IO Valerie Aurora Henson
2008-11-13 20:26 ` [RFC PATCH 15/17] Convert to inode/block/bitmap/table loc()/loc_set() functions Andreas Dilger
2008-11-13 20:24 ` [RFC PATCH 14/17] super->s_*_blocks_count -> ext2fs_*_blocks_count() Andreas Dilger
2008-11-14 3:25 ` Valerie Aurora Henson
2008-11-14 16:24 ` Eric Sandeen
2008-11-13 20:14 ` [RFC PATCH 13/17] Support 48-bit file acl blocks Andreas Dilger
2008-11-14 2:30 ` Valerie Aurora Henson
2008-11-13 20:04 ` [RFC PATCH 11/17] Fix overflow in calculation of total file system blocks Andreas Dilger
2008-11-14 2:34 ` Valerie Aurora Henson
2008-11-14 3:10 ` 64-bit inode support in e2fsprogs? (was Re: [RFC PATCH 11/17] Fix overflow in calculation of total file system blocks) Valerie Aurora Henson
2008-11-14 20:32 ` Andreas Dilger
2008-11-13 19:57 ` [RFC PATCH 10/17] signed int -> blk64_t to fix bugs at 2^31 - 2^32 blocks Andreas Dilger
2008-11-14 2:38 ` Valerie Aurora Henson
2008-11-14 3:42 ` Eric Sandeen
2008-11-14 3:54 ` Valerie Aurora Henson
2008-11-14 4:04 ` Eric Sandeen
2008-11-14 14:24 ` Theodore Tso
2008-11-14 20:35 ` Andreas Dilger
2008-11-16 15:06 ` Theodore Tso
2008-11-13 19:54 ` [RFC PATCH 09/17] Add progress bar for allocating block tables - takes forever on large Andreas Dilger
2008-11-14 2:45 ` Valerie Aurora Henson
2008-11-12 20:47 ` [RFC PATCH 04/17] Implement 64-bit "bitarray" bmap ops Andreas Dilger
2008-11-14 2:59 ` Valerie Aurora Henson
2008-11-12 20:25 ` [RFC,PATCH] 64-bit support for e2fsprogs Andreas Dilger
2008-11-13 20:30 ` Theodore Tso
2008-11-14 3:01 ` Valerie Aurora Henson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081114030133.GG20637@shell \
--to=vaurora@redhat.com \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).