From: Theodore Ts'o <tytso@mit.edu>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-ext4@vger.kernel.org
Subject: Re: ext4 wrote extents on ext2 fs?
Date: Fri, 9 Jan 2015 18:30:09 -0500 [thread overview]
Message-ID: <20150109233009.GB31554@thunk.org> (raw)
In-Reply-To: <1420841908.7511.1.camel@sipsolutions.net>
On Fri, Jan 09, 2015 at 11:18:28PM +0100, Johannes Berg wrote:
> Hi,
>
> I'm running - on an oldish kernel 3.14.26 - an ext2 filesystem with the
> ext4 module, on a 1GB USB pendrive. Today the system failed to come up
> properly (it's a small router providing my internet connectivity) and
> this is what e2fsck had to say about the filesystem:
>
> # e2fsck /dev/sdb1
> e2fsck 1.42.12 (29-Aug-2014)
> extroot contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Inode 15817 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15818 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15819 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15820 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15821 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15822 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15823 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
> Inode 15824 has EXTENTS_FL flag set on filesystem without extents support.
> Clear<y>? yes
>
> As you can see, the inodes that somehow ended up with extents were
> deleted in the process of this - perhaps this shouldn't actually have
> been a problem for ext4 reading the filesystem? However, based on the
> symptoms of the device failure I reckon that the contents of those files
> was corrupted.
What I suspect happened is that some kind of garbage --- perhaps
simply a single 4k block of 0xFF's --- got written into the inode
table. This would trigger this sort of complaint from e2fsck.
> Perhaps this is just a consequence of check ordering though - maybe if
> the inode flags get corrupted then the EXTENTS flag is just the first
> one that will be tested in the e2fsck code?
Yes, this is one of the first things that e2fsck 1.42.x would test
for.
- Ted
next prev parent reply other threads:[~2015-01-09 23:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 22:18 ext4 wrote extents on ext2 fs? Johannes Berg
2015-01-09 23:30 ` Theodore Ts'o [this message]
2015-01-09 23:38 ` Johannes Berg
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=20150109233009.GB31554@thunk.org \
--to=tytso@mit.edu \
--cc=johannes@sipsolutions.net \
--cc=linux-ext4@vger.kernel.org \
/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.