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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
