All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Valerie Aurora <vaurora@redhat.com>
Cc: linux-ext4@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>
Subject: Re: Fix device too big bug in mainline?
Date: Sat, 1 Aug 2009 20:28:33 -0400	[thread overview]
Message-ID: <20090802002833.GB8680@mit.edu> (raw)
In-Reply-To: <20090730215302.GA31141@shell>

On Thu, Jul 30, 2009 at 05:53:02PM -0400, Valerie Aurora wrote:
> Hi all,
> 
> Currently, e2fsprogs will fail to create a file system if the
> underlying device is "too big" - even if we specify a number of blocks
> to use that is in range:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=485236
> 
> This is fixed in the current pu branch, but more as a side effect of
> an enormous 64-bit rewrite.
> 
> Ted, any plans to pull this into mainline?

We have a special case as of v1.41.4 so that if someone creates a 16TB
partition, we'll treat it as having 16TB - 1 minus blocks.

Yes, I'm working on merging the 64-bit patches into mainline; and so
far we have about 25% or so of the patches merged into the master
branch.  It's been somewhat slow going, since I've many other things
on my plate, and because I've wanted to do a lot of QA while doing the
merge.  I've found more than a few bugs simply by doing code
inspection while merging the patches one at a time.

How much do we care about this specific bug as something that needs to
be fixed ASAP?  We already have something for a 16TB logical volume,
since that is what is most likely to be created with lvcreate.  But do
we consider it a common case where someone creates a 32TB logical
volume, but intends to create a 16TB (minus 1 block) filesystem, that
needs to be urgently fixed?

            					- Ted

  reply	other threads:[~2009-08-02  0:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-30 21:53 Fix device too big bug in mainline? Valerie Aurora
2009-08-02  0:28 ` Theodore Tso [this message]
2009-08-02  2:22   ` Theodore Tso
2009-08-02  3:49     ` Theodore Tso
2009-08-03 20:11     ` Valerie Aurora
2009-08-03 20:27     ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora
2009-08-03 22:56       ` Valerie Aurora
2009-08-04  6:40       ` Julia Lawall
2009-08-04 14:48       ` Theodore Tso
2009-08-04 18:18         ` Valerie Aurora
2009-08-04 19:24           ` Andreas Dilger
2009-08-04 19:58             ` Valerie Aurora
2009-08-04 20:32           ` Theodore Tso
2009-08-04 18:28     ` Fix device too big bug in mainline? Valerie Aurora
2009-08-04 20:41       ` Theodore Tso
2009-08-04 21:29         ` Valerie Aurora
2009-08-04 22:12           ` Theodore Tso
2009-08-04 23:56       ` Theodore Tso
2009-08-03 18:04   ` Valerie Aurora

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=20090802002833.GB8680@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=vaurora@redhat.com \
    /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.