On Thu, Feb 15, 2007 at 09:20:21AM -0500, Theodore Tso wrote: > > It's actually not the case that fsck will complete the truncate for > file A. The problem is that while e2fsck is processing indirect > blocks in pass 1, the block which is marked as file A's indirect block > (but which actually contain's file B's data) gets "fixed" when e2fsck > sees block numbers which look like illegal block numbers. So this > ends up corrupting file B's data.
Ah, that's what happens. Thanks for the clarification. > This is actually legal end result, BTW, since it's POSIX states the > result of fsync() is undefined if the system crashes. Technically And POSIX also states that sync() is only required to schedule the writes, but may return before the actual writing is done. Looks like the only way you can guarantee data is on-disk according to POSIX is to reboot the system after every synchronous write. Man, we file systems developers sure have it easy! -VAL - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
