Re: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)

[Jens Axboe <axboe@suse.de>]

On Mon, Mar 07 2005, Junfeng Yang wrote:
> 
> Hi,
> 
> FiSC (our FS checker) issues a warning on ext2, complaining that crash
> after fsync causes file system to corrupt.  FS corrupts in two different
> ways: 1. file contains illegal blocks (such as block # -2) 2. one block
> owned by two different files.
> 
> I diagnosed the warning a little bit and it appears that this warning can
> be triggered by the following steps:
> 
> 1. a file is truncated, so several blocks are freed
> 2. a new file is created, and the blocks freed in step 1 are reused
> 3. fsync on the new file
> 4. crash and run fsck to recover.
> 
> fsync should guarantee that a specific file is persistent on disk.
> Presumably, operations on other files should not mess up with the file we
> just fsync (true ?)  However, I also understand that ext2 by default
> relies on e2fsck to provide file system consistency.  Do you guys consider
> the above warning as a bug or not?  Any clarification on this will be very
> helpful.

fsync on ext2 only really guarantees that the data has reached
the disk, what the disk does it outside the realm of the fs.
If the ide drive has write back caching enabled, the data just
might only be in cache. If the power is removed right after fsync
returns, the drive might not get a chance to actually commit the
write to platter.

This isn't a patch suitable for inclusion, but you could try
and repeat with it applied. Does it fix the file corruption for
you?


===== fsync.c 1.9 vs edited =====
--- 1.9/fs/ext2/fsync.c	2004-04-12 19:54:19 +02:00
+++ edited/fsync.c	2005-03-07 11:44:25 +01:00
@@ -47,5 +47,7 @@
 	err = ext2_sync_inode(inode);
 	if (ret == 0)
 		ret = err;
+
+	blkdev_issue_flush(inode->i_sb->s_bdev, NULL);
 	return ret;
 }

-- 
Jens Axboe