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.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
