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@xxxxxxx> 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
