Re: Should Never Happen: Resize Inode Corrupt

["Theodore Ts'o" <tytso@mit.edu>]

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