[ ... ] >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
