All of lore.kernel.org
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, tytso@mit.edu
Cc: linux-ext4@vger.kernel.org
Subject: Re: 64bit + resize2fs... this is Not Good.
Date: 14 Nov 2012 22:43:03 -0500	[thread overview]
Message-ID: <20121115034303.3956.qmail@science.horizon.com> (raw)
In-Reply-To: <20121114233854.GD24980@thunk.org>

> It's actually not 1000x times.  It's a 1000x times up to a maximum of
> 1024 current and reserved gdt blocks (which is the absolute maxmimum
> which can be supported using resize_inode feature).  Contrary to what
> you had expected, it's simply not possible to have 2048 or 4096
> reserved gdt blocks using the resize_inode scheme.  That's because it
> stores in the reserved gdt blocks using an indirect/direct scheme, and
> that's all the sapce that we have.  (With a 4k block, and 4 bytes per
> blocks --- the resize_inode scheme simply completely doesn't work if
> above 16TB since it uses 4 byte block numbers --- 4k/4 = 1024 block group
> descriptors.)

Er... you can't use extents?  The blocks *are* all contiguous.

>> Yeah, I see how that would cause problems, as you ask for 51.5G of
>> resize range.  What pisses me off is that I asked for 64 TiB!
>> (-E resize=17179869184)

> Yes, mke2fs should have issued an error message to let you know
> there's no way it could honor your request.

As long as I get to be at least a *little* bit grumpy that *both*
mke2fs and resize2fs, when asked to do something they couldn't to,
failed to produce any sort of error message, but silently f***ed it up.

> Again, I'm really sorry; you were exploring some of the less well
> tested code paths in e2fsprogs/resize2fs.  :-(

I seem to be developing a knack for that this last couple of months. :-(

I *thought* I was doing the obvious thing.

All I set out to do was expand a 10 TB RAID to 22 TB.
Really, everything I did I *thought* I chose the *safest*
possible option.

1. Restripe RAID
2. Try to resize FS, hit 16 TB limit.
3. Restripe RAID back down.
4. Create new 8 TB RAID from new drives
5. Format with 64-bit ext4, telling mke2fs that I will be resizing later.
5a. Fight with bug in mke2fs while doing so.

6. Copy over files from 32-bit FS
7. Destroy old RAID, and add drives to new RAID
8. Restripe up to 22 TB (again!)
9. Resize file system.  Personally, an off-line technique
  "feels safer" than on-line, so I went with that.

10. Kablooie!

Other than skipping the first 3 steps, what was I supposed to
do different?

  reply	other threads:[~2012-11-15  3:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-14  3:51 64bit + resize2fs... this is Not Good George Spelvin
2012-11-14  5:43 ` Theodore Ts'o
2012-11-14  6:42   ` George Spelvin
2012-11-14  7:12   ` George Spelvin
2012-11-14  7:20   ` George Spelvin
2012-11-14 20:39     ` Theodore Ts'o
2012-11-14 21:04       ` Theodore Ts'o
2012-11-14 23:26       ` George Spelvin
2012-11-14 23:38         ` Theodore Ts'o
2012-11-15  3:43           ` George Spelvin [this message]
2012-11-14  6:27 ` George Spelvin

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=20121115034303.3956.qmail@science.horizon.com \
    --to=linux@horizon.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 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.