> Really, I don't know what to add to this sentence. Without> implementing partially ordered writes, this is a problem. Now, even> the author admits that this is "unlikely" to happen, and practical> experience says that it is at best extremely rare. Still, nothing> that the author said appears to be FUD or incorrect from what I know.

Bang head on wall time. You need more than partially ordered writes tosolve what you describe. Consider adding a 4K block to a file. You mustwrite

The inode - new size, block count The indirect block (maybe blocks) with the block number The data block.

Now you can order those however you like as strictly as you like I canstill turn the power off at any point.

So potentially the data update is lost on a power off because the inodeor indirect block isnt written.

BSD (strict) update inode update indirect block update data block

And if I turn the power off your file is 4K larger, consistent with itsmeta-data and containing 4K of unspecified random previous data - eg a previouscopy of the shadow password file, a private note to your girlfriend whatever..

You can pick any order of update you like, you still lose. Only a transactionbased file system where you atomically write a transaction, then commit itis capable of resolving the situation.

Anyone who can't grasp such basic facts shouldnt be writing books on filesystems

Alan

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/