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: Jim Meyering <jim@meyering.net>, ext <linux-ext4@vger.kernel.org>,
	Eric Sandeen <sandeen@redhat.com>
Subject: Re: with -b N and block count, should mkfs.ext4 fail with dev-too-big?
Date: Wed, 11 Feb 2009 14:26:17 -0500	[thread overview]
Message-ID: <20090211192617.GA9501@shell> (raw)
In-Reply-To: <20090211140905.GG29220@mini-me.lan>

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

  reply	other threads:[~2009-02-11 19:26 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 [this message]
2009-02-11 19:32     ` Eric Sandeen
2009-02-11 21:17       ` Valerie Aurora Henson

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=20090211192617.GA9501@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 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).