> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
