Re: [RFC] relaxed barrier semantics

[Ric Wheeler <rwheeler@redhat.com>]

On 07/29/2010 03:59 PM, James Bottomley wrote:
> On Thu, 2010-07-29 at 15:56 -0400, Ric Wheeler wrote:
>    
>> On 07/29/2010 03:49 PM, Christoph Hellwig wrote:
>>      
>>> On Thu, Jul 29, 2010 at 03:44:31PM -0400, Ric Wheeler wrote:
>>>
>>>        
>>>> I confess that I am a bit fuzzy on FUA, but think that it means that any
>>>> FUA tagged IO will go down to persistent store before returning.
>>>>
>>>>          
>>> Exactly.
>>>
>>>
>>>        
>>>> If so, then all order dependent IO would need to be issued in order and
>>>> tagged with FUA. It would not suffice to tag just the commit record as
>>>> FUA, or do I misunderstand what FUA does?
>>>>
>>>>          
>>> The commit record is ext3/4 specific terminalogy.  In xfs we just have
>>> one type of log buffers, and we could tag that as FUA.  There is very
>>> little other depenent I/O, but if that is present we need a pre-flush
>>> for it anyway.
>>>
>>>
>>>        
>> I assume that for ext3 it would get more complicated depending on the
>> journal mode. In ordered or data journal mode, we would have to write
>> the dependent non-journal data tagged with FUA, then the FUA tagged
>> transaction and finally the FUA tagged commit block.
>>
>> Not sure how FUA performs, but writing lots of small tagged writes is
>> probably not good for performance...
>>      
> That's basically everything FUA ... you might just as well switch your
> cache to write through and have done.
>    

I think that for data ordered mode that is all of the data more or less 
would get tagged. For data journal, would we have to send 2x the write 
workload down with tags?  I agree that this would be dubious at best.

Note that using the non-FUA cache flush commands, while brute force, 
does have a clear win on slower devices (S-ATA specifically).  Each time 
I have looked, using the write cache enabled on S-ATA was a win (big win 
on streaming write performance, not sure why).

On SAS drives, the flush barriers were not as large a delta (do not 
remember which won out).

> This, by the way, is one area I'm hoping to have researched on SCSI
> (where most devices do obey the caching directives).  Actually see if
> write through without flush barriers is faster than writeback with flush
> barriers.  I really suspect it is.
>
> James
>    

There are clearly much better ways to do this. Even the flushes, if we 
could flush ranges that matched the partition under the file system, 
would be better than today where we flush the entire physical device.

Ric