I'm really curious how the superblock got into this configuration:
> > > ~ # tune2fs -l /dev/sde1
> > > tune2fs 1.44.5 (15-Dec-2018)
> > > Filesystem volume name: USERDATA
...
> > > Filesystem features: ext_attr resize_inode dir_index filetype extent 64bit large_dir sparse_super large_file
There is no journal features here at all
> > > Journal UUID: 00000000-1b00-0000-0000-000000000000
> > > Journal inode: 131072
A journal UUID and inode should never be set at the same time. But
this is a lot more than a single bit flip. The rest of the sueprblock
looks sane, so it's not a matter of someone writing garbage over the
on-disk copy.
Maybe a wild pointer smashing two bytes in the middle of the
superblock?
In any case, this is something where we should probably add sanity
checks so kernel will refuse to mount a file system like this --- and
e2fsck should also try to see if the backup superblock is sane and try
using it. (We could also teach e2fsck to offer to clear these fields so
a user won't have to use debugfs's ssv command if falling back to
backup superblock doesn't work.)
I'm still really wondering how this could have happened, though...
- Ted
