linux-ext4 - Re: 64bit + resize2fs... this is Not Good.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20121115034303.3956.qmail@science.horizon.com>
Date:	14 Nov 2012 22:43:03 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, tytso@....edu
Cc:	linux-ext4@...r.kernel.org
Subject: Re: 64bit + resize2fs... this is Not Good.

> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html