[ ... ]

quoted

What really bothers me is that there's no obvious need for
barriers at the device level if the file system is just a bit
smarter and does it's own async io (like aio_*), because you
can track writes outstanding on a per-fd basis,

The drive itself may still re-order writes, thus can cause
corruption if halfway the power goes down. [ ... ] Barriers need
to travel all the way down to the point where-after everything
remains in-order. [ ... ] Whether the data has made it to the
drive platters is not really important from a barrier point of
view, however, iff part of the data made it to the platters, then
we want to be sure it was in-order. [ ... ]

But this discussion is backwards, as usual: the *purpose* of any
kind of barriers cannot be just to guarantee consistency, but also
stability, because ordered commits are not that useful without
commit to stable storage.

If barriers guarantee transaction stability, then consistency is
also a consequence of serial dependencies among transactions (and
as to that per-device barriers are a coarse and very underoptimal
design).

Anyhow, barriers for ordering only have been astutely patented
quite recently:

  http://www.freshpatents.com/Transforming-flush-queue-command-to-memory-barrier-command-in-disk-drive-dt20070719ptan20070168626.php

Amazing new from the patent office.y

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs