It's not clear if disabling write cache is enough, when ext3 is mounted with barrier=0 (the current default). That stops the disk from reordering writes, but the kernel elevator is still able to reorder writes, when barrier=0, before sending them to the disk. Setting barrier=1 has the dual effect of telling the kernel not to reorder requests around barrier writes, and ideally passing that constraint to the disk as well.
But isn't it impossibly naive for ext3 to assume writes it submits to the block layer get realized on disk in the order submitted? I assume designers weren't that naive and, when working without barriers, ext3 withholds writes from the block layer until every prerequisite write has completed.
The value of barriers is supposed to be that ext3 doesn't have to let the queue run dry, with its attendant throughput slowdown. Ext3 can submit writes for before the commit record, the commit record, and after the commit record, with barriers placed appropriately in the stream, and the block layer will take care of enforcing the required ordering.
The fact that "write completed" doesn't imply the data is persistent across a disk drive power failure (and furthermore the gaining of that persistence isn't in any particular order) is an orthogonal issue. Which code deals with it depends upon whether ext3 uses barriers or not. (And ISTR the block layer doesn't provide any mechanism separate from barriers to deal with it, so if you don't use barriers=1, it doesn't get dealt with).
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds