On Tue, Jan 30, 2018 at 12:39:04AM +0100, Hanno 'Rince' Wagner wrote:
> Package: e2fsprogs
> Version: 1.43.8
> Severity: normal
> Tags: upstream
>
> I have a broken filesystem and try to fsck it. Unfortunately, it is
> ~21TB large and therefore not very easy to duplicate with dd or
> similar tools for further inspection. when I do an fsck, fsck
> doesn't find the superblock or sais that the superblock is
> corrupted. Since this happens on every superblock dumpe2fs has told
> me I don't think this is a problem with the filesystem but either
> with the display via dumpe2fs or the parameter in the fsck-binary.
Unfortunately, your file system is corrupted, and I suspect it was
caused by your running an off-line (while unmounted) resize2fs using
e2fsprogs 1.42.x. In fact, unless you are using the very latest
1.43.x version of e2fsprogs, there were bugs in resize2fs's off-line
resizing for 64-bit file systems > 16 TiB that could badly corrupting
the file system and potentially causing data loss.
Since the bug was in resize2fs, it ended up writing the bogus values
to all of your backup superblocks, which explains what you are seeing.
You can fix superblock this via:
# debugfs -w /dev/sdXX
debugfs: set_super_value s_reserved_gdt_blocks 0
debugfs: features ^resize_inode
debugfs: quit
You'll then have to force a check:
# e2fsck -fy /dev/sdXX
Unfortunately you may still find that data has been lost --- but that
would have been caused by the use of a buggy resize2fs.
For future reference, using on-line resize (while the file sytem is
mounted) is much safer. As is doing a full backup before you resize
the file system.
Sorry....
- Ted
