Leon Woestenberg wrote:
> On 15 dec 2008, at 23:50, Peter Grandi wrote:
>> [ ... ]
>>>> The purpose of barriers is to guarantee that relevant data is
>>>> known to be on persistent storage (kind of hardware 'fsync').
>>> [ ... ] Unfortunately in my understanding none of this is
>>> reflected by Documentation/block/barrier.txt
>> But we are talking about XFS and barriers here. That described
>> just a (flawed, buggy) mechanism to implement those. Consider
>> for example:
>> In any case as to the kernel "barrier" mechanism, its
>> description is misleading because it heavily fixates on the
>> ordering issue, which is just a consequence, but yet mentions
>> the far more important "flush/sync" aspect.
>> Still, there is a lot of confusion about barrier support and
>> what it means at which level, as reflected in several online
>> discussions and the different behaviour of different kernel
> The semantics of a barrier are whatever semantics we describe to it.
> So we can continue to be confused about it.
> I strongly disagree on the ordering issue being a side effect.
> Correct ordering can be proven to be enough to provide transactional
> correctness, enough to ensure that filesystems can not get corrupted
> on power down.
> Using barriers to guarantee that (all submitted) write requests
> (before the barrier) made it to the medium are a stronger predicate.
> The Linux approach and documentation talks about the first type of
> semantics (which I rather like for them being strong enough and not
Agreed. I'll have a look over those (wiki) faq entries and make sure
they're not confusing cache flushes with ordering requirements.