From: "Theodore Ts'o" <tytso@mit.edu>
To: Ede Wolf <listac@nebelschwaden.de>
Cc: linux-ext4@vger.kernel.org
Subject: Re: e2fsck fails on non journalled partition
Date: Sun, 17 Mar 2019 17:53:15 -0400 [thread overview]
Message-ID: <20190317215315.GD23356@mit.edu> (raw)
In-Reply-To: <c2be64f5-d0fc-f66b-36ab-ab601301cbed@nebelschwaden.de>
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
next prev parent reply other threads:[~2019-03-17 21:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 19:28 e2fsck fails on non journalled partition Ede Wolf
2019-03-16 2:57 ` Andreas Dilger
2019-03-16 9:10 ` Ede Wolf
2019-03-17 21:53 ` Theodore Ts'o [this message]
2019-03-17 22:51 ` Ede Wolf
2019-03-18 14:35 ` Ede Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190317215315.GD23356@mit.edu \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=listac@nebelschwaden.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.