linux-ext4 - Re: Online resize issue with 3.13.5 & 3.15.6

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140726135652.GC6725@thunk.org>
Date:	Sat, 26 Jul 2014 09:56:52 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Brad Campbell <lists2009@...rfbargle.com>
Cc:	Azat Khuzhin <a3at.mail@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: Online resize issue with 3.13.5 & 3.15.6

On Sat, Jul 26, 2014 at 09:46:20PM +0800, Brad Campbell wrote:
> This was the first resize of this FS. Initially this array was about 15T.
> About 12 months ago I attempted to resize it up to 19T and bumped up against
> the fact I had not created the initial filesystem with 64 bit support, so I
> cobbled together some storage and did a backup/create/restore. At that point
> I would probably have specified resize_inode manually as an option (as
> reading the man page it looked like a good idea as I always had plans to
> expand in future) to mke2fs along with 64bit. Fast forward 12 months and
> I've added 2 drives to the array and bumped up against this issue. So it was
> initially 4883458240 blocks. It would have been created with e2fsprogs from
> Debian Stable (so 1.42.5).

So mke2fs 1.42.11 does the right thing (although it really should just
tell you that there's no point using the resize_inode).

% mke2fs -Fq -t ext4 -O resize_inode,64bit /mnt/foo.img 19T
/mnt/foo.img contains a ext4 file system
	     created on Sat Jul 26 09:54:30 2014

% dumpe2fs -h /mnt/foo.img  | grep "Reserved GDT"
dumpe2fs 1.42.11 (09-Jul-2014)

% debugfs -R "stat <7>" /mnt/foo.img
debugfs 1.42.11 (09-Jul-2014)
Inode: 7   Type: bad type    Mode:  0000   Flags: 0x0
Generation: 0    Version: 0x00000000
User:     0   Group:     0   Size: 0
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x00000000 -- Wed Dec 31 19:00:00 1969
atime: 0x00000000 -- Wed Dec 31 19:00:00 1969
mtime: 0x00000000 -- Wed Dec 31 19:00:00 1969
Size of extra inode fields: 0
BLOCKS:

> I can't test this to verify my memory however as I don't seem to be able to
> create a sparse file large enough to create a filesystem in. I appear to be
> bumping up against a 2T filesize limit.

Yep, when I do this testing I create a loopback mounted (sparse) xfs
file system, so I can create the sparse files needed to do this sort
of testing.

My guess is that 1.42.5 is not doing the right thing, although I
haven't had a chance to test it yet.

					- Ted
--
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