an alternative to the application barrier() call
Posted Sep 11, 2009 15:05 UTC (Fri) by anton
In reply to: what's needed is a application barrier() call
Parent article: POSIX v. reality: A position on O_PONIES
write1 write2 write3 barrier write4 write5
will guarantee that writes 1-3 will hit the disk before writes 4 and 5
but says nothing about the ordering or timeing of the two seperate sets.
An alternative would be to just extend POSIX logical ordering
guarantees (as visible by other processes) to the post-recovery state.
That would mean that the file system would implicitly put a barrier
between any of the writes in your example.
The question is: how much would this guarantee cost compared to
what you have in mind? In a copy-on-write filesystem it could cost
very little, if anything. The file system could still perform the
user writes in any order (all of them, not just a subset), but just
would never commit a write for which the earlier writes have not been
performed yet. For journaled file systems the reasoning is more
complex, but I believe that in the usual case (writing new data) the
cost is also very small.
The benefits of this guarantee are that it makes programming
easier, and especially testing easier: If your files are always
consistent as seen by other processes, they will also be consistent in
case of a crash or power outage; no need to pull the power plug in
order to test the crash resilience of your application.
to post comments)