From: "Theodore Ts'o" <tytso@mit.edu>
To: Valdis.Kletnieks@vt.edu
Cc: root@chaos.analogic.com, Junfeng Yang <yjf@stanford.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ext2-devel@lists.sourceforge.net, mc@cs.Stanford.EDU,
madan@cs.Stanford.EDU, "David L. Dill" <dill@cs.Stanford.EDU>
Subject: Re: [Ext2-devel] Re: [CHECKER] e2fsck writes out blocks out of order, causing root dir to be corrupted (ext3, linux 2.4.19, e2fsprogs 1.34)
Date: Tue, 11 May 2004 23:41:23 -0400 [thread overview]
Message-ID: <20040512034123.GA6469@thunk.org> (raw)
In-Reply-To: <200405120309.i4C39jUZ017062@turing-police.cc.vt.edu>
On Tue, May 11, 2004 at 11:09:45PM -0400, Valdis.Kletnieks@vt.edu wrote:
>
> I suspect this bug is merely a special case of "your filesystem can
> get scrogged if something's doing caching behind your back" - the
> same sort of issues that prompted recent "flush the IDE cache on
> shutdown" fixes, and the well-known issues with using journalling
> file systems on a file-backed loopback device.
No, not really. This is the case of "we moved code that was original
kernel-space to user space", and we failed to simulate certain
functions, such as sync_blockdev().
> Having said that, I admit being surprised that their demonstration
> test case is *that* simple - that's a truly small number of I/Os to
> get it into a repeatably corruptible state. I'm sure many of us
> have a mental image of these class of failures as being heisenbugs,
> dependent on the cache contents.
Well, the demonstration test case *wasn't* that simple. It required
the system crashing twice at very specific points. Once to create the
filesystem requiring a journal replay, and then a second crash at
exactly the right time in the middle of e2fsck's journal replaying
code. This failure would be fairly hard to replicate in real-life
conditions, since it would require to crashes in quick succession, at
very carefully chosen points, although if you had really flaky AC
mains, I suppose it might be considered a more likely failure case.
> Hardly - the class of errors is one that does (or should) concern
> the kernel community - and I don't consider identifying a "your
> filesystem *will* be toast if you get into this repeatable scenario"
> a troll. At the very least, we can consider what additional
> hardening we can do to either the kernel or userspace to make sure
> that we don't re-order the blocks - note the key phrase here:
>
> "Neither of these pay attention to the journaling constraints of
> EXT3 and JBD."
Well, actually it was the e2fsprogs user space code that wasn't paying
attention t the journalling constraints, mainly because we had been we
weren't faithfully implementing sync_blockdev()/fsync_no_super(). The
patch to fix this in e2fsprogs was fairly simple.
- Ted
next prev parent reply other threads:[~2004-05-12 3:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-12 0:55 [CHECKER] e2fsck writes out blocks out of order, causing root dir to be corrupted (ext3, linux 2.4.19, e2fsprogs 1.34) Junfeng Yang
2004-05-12 1:49 ` [MC] " Junfeng Yang
2004-05-12 2:45 ` Richard B. Johnson
2004-05-12 3:09 ` Valdis.Kletnieks
2004-05-12 3:41 ` Theodore Ts'o [this message]
2004-05-12 3:19 ` Theodore Ts'o
2004-05-12 6:21 ` [MC] Re: [CHECKER] e2fsck writes out blocks out of order, Dawson Engler
2004-05-12 3:31 ` [CHECKER] e2fsck writes out blocks out of order, causing root dir to be corrupted (ext3, linux 2.4.19, e2fsprogs 1.34) Theodore Ts'o
2004-05-12 4:55 ` Junfeng Yang
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=20040512034123.GA6469@thunk.org \
--to=tytso@mit.edu \
--cc=Valdis.Kletnieks@vt.edu \
--cc=dill@cs.Stanford.EDU \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=madan@cs.Stanford.EDU \
--cc=mc@cs.Stanford.EDU \
--cc=root@chaos.analogic.com \
--cc=yjf@stanford.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).