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 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.