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
<[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/