linux-ext4 - Re: Should Never Happen: Resize Inode Corrupt

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: <CAB5bDOgXRPK4Bw-XaPqpFUbAbU7dGk+x9jeXUD_cJqWQASqjdA@mail.gmail.com>
Date:   Mon, 18 Mar 2019 01:24:16 -0400
From:   Burke Harper <go88team@...il.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: Should Never Happen: Resize Inode Corrupt

Correct.  The it was previously 36T.  A few weeks before that it was
28T.  The resize from 28T to 36T performed just fine.

I've upgraded to 1.44.5, cleared the resize_inode feature, and have
restarted e2fsck -f /dev/md0.

Thanks.  I'll check back periodically as this part seems to take a long while.


On Sun, Mar 17, 2019 at 5:19 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Sat, Mar 16, 2019 at 12:57:57PM -0600, Andreas Dilger wrote:
> > You could kill e2fsck and disable the resize_inode feature?  There is a different resize mechanism available now (meta_bg) that doesn't need it.
>
> It looks like the file system was previously 36T and you were trying
> to resize it to 51T.  Is that right?  The resize_inode feature should
> not have been present at all; it's not valid for file systems > 32TiB.
>
> The resize2fs in 1.42 is more than a little bit buggy when dealing
> with large file systems > 32TiB, and it sounds like there were some
> problems dealing with the transition from file systems smaller than 32
> TiB (where the resize_inode still works), and file systems > 32 TiB
> (where we use a new style of on-line resizing, called meta_bg.
>
> Hopefully that's because you used an old 1.42 resize2fs when you
> resized it up to 36 TiB, but we should test to make sure it's
> currently working correctly.
>
> Similarly, e2fsck shouldn't be even trying to deal with the resize
> inode if the file system size > 32 TiB.  (Or to be more
> accurate/pedantic, when the max. block number no longer fits in a
> 32-bit integer; although if someone is using a 1k or 2k block file
> system on a file system that larger, they have other problems.  :-)
>
> So yeah, the first thing I would use debugfs to clear the resize_inode
> feature:
>
> debugfs -w /dev/md0
> debugfs: features ^resize_inode
> debugfs: clri <7>
> debugfs: quit
>
> And then run e2fsck -f /dev/md0.
>
>                                         - Ted