linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).