All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valerie Aurora Henson <vaurora@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Theodore Tso <tytso@mit.edu>, Jim Meyering <jim@meyering.net>,
	ext <linux-ext4@vger.kernel.org>
Subject: Re: with -b N and block count, should mkfs.ext4 fail with dev-too-big?
Date: Wed, 11 Feb 2009 16:17:09 -0500	[thread overview]
Message-ID: <20090211211709.GB9501@shell> (raw)
In-Reply-To: <499327D2.8010502@redhat.com>

On Wed, Feb 11, 2009 at 01:32:34PM -0600, Eric Sandeen wrote:
> Valerie Aurora Henson wrote:
> > On Wed, Feb 11, 2009 at 09:09:05AM -0500, Theodore Tso wrote:
> >> On Wed, Feb 11, 2009 at 01:50:39PM +0100, Jim Meyering wrote:
> >>> FWIW, I was trying to create an ext4 file system with more than 2^32
> >>> blocks to demonstrate a parted bug fix, but with the particular device
> >>> I was using, I couldn't even create one with 2^31-1 blocks.
> >>>
> >>> When I try to create an ext4 file system specifying both block size and
> >>> the number of blocks, the size of the underlying device should not matter,
> >>> as long as it is large enough.
> >> Oops, my fault.  I fixed the case where the device was exactly 16TB
> >> (as in created via lvcreate --size 16TB, but the fix was very minimal,
> >> since it was just before a maintenance release.  I didn't consider (or
> >> test) the case where the device was larger than or equal to 2*32
> >> blocks (given a specified blocksize, or 4k if no blocksize was
> >> specified), and an explicit block size less than 2*32 was specified.
> >>
> >> I'll put it on my todo list to fix for e2fsprogs 1.41.5.
> > 
> > Note that this is fixed in effect by the 64bit patches, since we use
> > the 64bit get device size function.
> > 
> > git://git.kernel.org/pub/scm/fs/ext2/val/e2fsprogs.git
> > 
> > Branch "shared-64bit".
> > 
> > -VAL
> 
> That won't fix it for ext3 though will it?  (not that I've looked in
> detail) but the issue is not whether we can properly get the device
> size; it's that the device size, rather than the filesystem size, is
> checked for overflow vs. the filesystem's limits...

Without actually going to the effort of trying to understand that code
again :), what I remember is that it's the order of the checks that
mattered.  When we used the 32-bit device size function, that would
fail before we got around to checking the user-specified number of
blocks to be in range.  Now the 64-bit call works and we can go on to
the range check for the user-specified number of blocks.

At any rate, it works for 2^31-1 4096 byte blocks:

[val@clunky e2fsprogs]$ ls -lh /terabyte/20TB -rw-rw-r-- 1 val val 19T 2009-02-11 13:11 /terabyte/20TB
[val@clunky e2fsprogs]$ ~/src/build/misc/mke2fs -b 4096 -t ext3 /terabyte/20TB `echo '2*1024^3-1'|bc`
mke2fs 1.41.4 (27-Jan-2009)
/terabyte/20TB is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
536870912 inodes, 2147483647 blocks
[etc]

It doesn't work for 1024 byte blocks - fails on number of inodes no
matter how few inodes I specify.  This might be a bug but I don't have
time to check it out right now.

-VAL

      reply	other threads:[~2009-02-11 21:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 12:50 with -b N and block count, should mkfs.ext4 fail with dev-too-big? Jim Meyering
2009-02-11 14:09 ` Theodore Tso
2009-02-11 19:26   ` Valerie Aurora Henson
2009-02-11 19:32     ` Eric Sandeen
2009-02-11 21:17       ` 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=20090211211709.GB9501@shell \
    --to=vaurora@redhat.com \
    --cc=jim@meyering.net \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.