linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Valerie Henson <val_henson@linux.intel.com>
To: 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>
Subject: Fix(es) for ext2 fsync bug
Date: Wed, 14 Feb 2007 11:54:54 -0800	[thread overview]
Message-ID: <20070214195453.GB7521@nifty> (raw)

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

             reply	other threads:[~2007-02-14 19:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-14 19:54 Valerie Henson [this message]
2007-02-14 20:31 ` Fix(es) for ext2 fsync bug David Chinner
2007-02-14 21:26   ` Dave Kleikamp
2007-02-14 23:32     ` David Chinner
2007-02-14 21:08 ` sfaibish
2007-02-15 14:20 ` Theodore Tso
2007-02-15 15:09   ` Dave Kleikamp
2007-02-15 15:59     ` sfaibish
2007-02-15 16:39       ` Dave Kleikamp
2007-02-15 17:15         ` Theodore Tso
2007-02-15 17:52           ` sfaibish
     [not found]         ` <21e789ec0702151111v4cb2aa8dqa168c886cb909c9@mail.gmail.com>
2007-02-15 19:26           ` Dave Kleikamp
2007-02-15 18:54       ` Dawson Engler
     [not found]         ` <21e789ec0702151118x1c6af801gd34981d72db0f5b2@mail.gmail.com>
     [not found]           ` <21e789ec0702151128x744f61e5lb24d2da972af185a@mail.gmail.com>
2007-02-16  1:18             ` Theodore Tso
2007-02-20 21:13     ` Valerie Henson
     [not found]       ` <21e789ec0702201330x1c2706b7kcd055b97cb37e0e@mail.gmail.com>
2007-02-20 21:39         ` Valerie Henson
2007-02-20 21:47           ` Dawson Engler
2007-02-20 22:25           ` Dave Kleikamp
2007-02-20 21:30   ` Valerie Henson
2007-02-20 22:12     ` Erez Zadok

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=20070214195453.GB7521@nifty \
    --to=val_henson@linux.intel.com \
    --cc=csar@stanford.edu \
    --cc=engler@csl.stanford.edu \
    --cc=junfeng@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.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).