An alternative to the application barrier() call
Posted Sep 11, 2009 17:06 UTC (Fri) by anton
In reply to: an alternative to the application barrier() call
Parent article: POSIX v. reality: A position on O_PONIES
Barriers certainly don't prevent write merging. Why would they? A
barrier just means that logically later writes are not committed before
logically earlier writes, but they can become visible at the same
time. So you can merge as many writes across barriers as you want.
Ok, your formulation of barriers exclude the same-time option, but
apart from the lower performance, how could an external observer tell
whether two logical writes happened one after another or at the same
time? Once they are both committed, there is no difference.
As my posting explains, they also don't prevent reordering of
physical data writes, they only restrict which sets of writes are
committed by a commit.
Multiple small writes can be merged together into a large one.
BTW, most writes probably happen through libc buffers, and are
typically larger than one sector (unless most of your files are
smaller than one sector).
to post comments)