From: sfaibish <sfaibish@emc.com>
To: "Valerie Henson" <val_henson@linux.intel.com>,
linux-fsdevel@vger.kernel.org
Cc: "Can Sar" <csar@stanford.edu>, "Junfeng Yang" <junfeng@gmail.com>,
"Dawson Engler" <engler@csl.stanford.edu>,
"Theodore Ts'o" <tytso@mit.edu>,
"kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: Fix(es) for ext2 fsync bug
Date: Wed, 14 Feb 2007 16:08:49 -0500 [thread overview]
Message-ID: <op.tnrbozm7unckof@usensfaibisl2e.eng.emc.com> (raw)
In-Reply-To: <20070214195453.GB7521@nifty>
Val,
Maybe it is not only our (FS people) problem. We probably need to
bring the kernel people judge as ext2 and ext3 are the base Linux FS.
I add the kernel list for opinion.
/Sorin
On Wed, 14 Feb 2007 14:54:54 -0500, Valerie Henson
<val_henson@linux.intel.com> wrote:
> Just some quick notes on possible ways to fix the ext2 fsync bug that
> eXplode found. Whether or not anyone will bother to implement it is
> another matter.
>
> Background: The eXplode file system checker found a bug in ext2 fsync
> behavior. Do the following: truncate file A, create file B which
> reallocates one of A's old indirect blocks, fsync file B. If you then
> crash before file A's metadata is all written out, fsck will complete
> the truncate for file A... thereby deleting file B's data. So fsync
> file B doesn't guarantee data is on disk after a crash. Details:
>
> http://www.stanford.edu/~engler/explode-osdi06.pdf
>
> Two possible solutions I can think of:
>
> * Rearrange order of duplicate block checking and fixing file size in
> fsck. Not sure how hard this is. (Ted?)
>
> * Keep a set of "still allocated on disk" block bitmaps that gets
> flushed whenever a sync happens. Don't allocate these blocks.
> Journaling file systems already have to do this.
>
> -VAL
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
parent reply other threads:[~2007-02-14 22:03 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20070214195453.GB7521@nifty>]
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=op.tnrbozm7unckof@usensfaibisl2e.eng.emc.com \
--to=sfaibish@emc.com \
--cc=csar@stanford.edu \
--cc=engler@csl.stanford.edu \
--cc=junfeng@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=val_henson@linux.intel.com \
/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
all inboxes | Powered by JetHome®