linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Valerie Aurora <vaurora@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>
Subject: Re: Fix device too big bug in mainline?
Date: Mon, 3 Aug 2009 14:04:05 -0400	[thread overview]
Message-ID: <20090803180405.GC10853@shell> (raw)
In-Reply-To: <20090802002833.GB8680@mit.edu>

On Sat, Aug 01, 2009 at 08:28:33PM -0400, Theodore Tso wrote:
> 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?

I've only talked to one customer who ran into this problem, and they
were testing, not doing anything in production.  The bug is pretty
easy to workaround - just partition your device or shrink your logical
volume.  Obviously, there's no point in having a partition larger than
16TB without the 64-bit feature since you can't grow the file system
to larger than that.  On the other hand, it offends my sensibilities
to have a known bug in a release.

To me, it seems reasonable to wait to fix this bug until the 64-bit
stuff goes in, especially since you'd have to write a fix from
scratch, since you can't backport the 64-bit version.  However, you
are the maintainer; if you think it should be fixed sooner then I'll
go ahead and write it.

-VAL

      parent reply	other threads:[~2009-08-03 18:04 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
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 [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=20090803180405.GC10853@shell \
    --to=vaurora@redhat.com \
    --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).