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]

Date:	Mon, 28 Jul 2014 22:46:51 -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:
> 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).

Confirmed; debian stable's mke2fs version 1.42.5 does the wrong thing
if you do:

   mke2fs -t ext4 -O 64bit,resize_inode /mnt/foo.img  19T

It creates a file system which is has a resize_inode which --- well,
is in a format that the kernel isn't capable of handling and which is
not something that was originally intended.  The interesting thing is
that resize2fs 1.42.11 is apparently able to handle resizing the above
file system created with mke2fs 1.42.5.

Mke2fs 1.42.12 will avoid creating a resize_inode for file systems >
16T, so this situation doesn't arise.

I need to take a closer look to see if there's some way I can teach
the kernel to be able to deal with this file system, but for now, you
can work around it by using tune2fs to remove the resize_inode, and
after running e2fsck and remounting the file system, the on-line
resize will work correctly.

Cheers,

					- 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