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

[Jens Axboe <axboe@suse.de>]

On Tue, Mar 08 2005, Pavel Machek wrote:
> On Po 07-03-05 11:45:13, Jens Axboe wrote:
> > 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.
> 
> I *think* they are using emulation for their checker, so drivers
> lying about writes should not be problem.

Yes, Junfeng informed me of that later.

-- 
Jens Axboe