Re: [RFC] relaxed barrier semantics

[Tejun Heo <tj@kernel.org>]

On 07/28/2010 11:16 AM, Christoph Hellwig wrote:
> The problem is to emulate it properly on devices that do no actually
> support the FUA bit.  Of which we unfortunately have a lot given
> that libata by default disables the FUA support even if the device
> supports.

These were the reasons.

* Some controllers puke for FUA commands whether the device supports
  it or not.

* With the traditional strong barriers, it doesn't make much
  difference whether FUA is used or not.  The full queue has already
  been stalled and flushed by the time barrier write is issued and all
  that we save is overhead for a single command which doesn't make any
  difference to actual timing of completion.

* Low confidence in drives reporting FUA support.  New features in ATA
  world seldomly work well and I'm fairly sure there are devices which
  report FUA support and handle FUA writes exactly the same way as
  regular writes.  :-(

So, until now, it just wasn't worth the effort / risk.  If filesystems
can make use of more relaxed ordering including avoiding full flush
completely, it might make sense to revisit it.  But, in general, I
think most barriers, even when relaxed, would at least involve single
flush before the FUA write and in that case I'm pretty skeptical how
useful FUA write for the barrier itself would be.

Thanks.

-- 
tejun