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

[Junfeng Yang]

> 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.

Hi Jens,

Thanks for the reply.  I tried your patch, and also setting hdparm -W0.
The warning is still there.  This warning and the previous ones I reported
should be irrelevant to IDE drivers, as FiSC (our FS checker) doesn't
actually crash the machine but simulates a crash using a ramdisk.

It appears to me that this warning can be triggered by the following steps:

1. create a file A with several data blocks. fsync(A) to disk

2. truncate A to a smaller size, causing a few blocks to be freed.
However, they are only freed in memory.  The corresponding changes in
bitmaps haven't yet hit the disk.

3. create a file B with several data blocks.  ext2 will re-use the freed
blocks from step 2.

4. fsync(B).  Once fsync returns, crash.

At this moment, the truncate in step 2 hasn't reached the disk yet, so the
file A on disk still contains pointers to the freed blocks.  However, the
fsync(B) in step 4 flushes B's inode and other metadata to disk.  Now we
end up with a file system where a block is shared by two files.

I'm not sure how the invalid block number warning is triggered.

-Junfeng

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/