barrier and commit options?

[Ric Wheeler]

Miller, Mike (OS Dev) wrote:
> Ric Wheeler wrote: 
>
>   
>>> I hope this a proper forum for this inquiry. I'm the 
>>>       
>> maintainer of the HP Smart Array driver, cciss. We've had 
>> requests and now a bug report to support write barriers. 
>>     
>>> It seems that write barriers are primarily intended to 
>>>       
>> ensure the proper ordering of data from the disks write cache 
>> to the medium. Is this accurate?
>>     
>>> Thanks,
>>> -- mikem
>>>
>>>   
>>>       
>> Hi Mike,
>>
>> Without working barriers, you are especially open to metadata 
>> corruption
>> - If I remember the details correctly, Chris Mason has 
>> demonstrated a 50% chance of corruption directory entries in 
>> ext3 for example.
>>
>> In addition, barriers allows fsync to have real meaning since 
>> the target storage will flush its write cache & the user will 
>> have that fsync() data after a power outage.
>>
>> If you have a battery backed write cache (say, in a high end 
>> array) barriers can be ignored since the storage can 
>> effectively make that write cache non-volatile, but 
>> otherwise, this is pretty key for anyone wanting to maintain 
>> data integrity,
>>
>>     
> Hi Ric,
> That's what I getting at, array controllers with a battery backed write cache (BBWC). We disable the write cache on the physical disks and provide no mechanism to re-enable the cache except in some SATA configurations.
>
> So my real question is this: Given the fact that many Smart Array controllers ship with a BBWC, will write barriers offer any benefit? I think fsync does nothing on SA since it doesn't know how to flush the controller cache.
>
> If a user has no BBWC then all writes are completed all the way down to the disk medium before the command is completed back up to the driver.
>
> Thanks,
> -- mikem
>   

In this case (or whenever the write cache is disabled on the disk) the 
barrier ops don't do anything for us... Some devices simply ignore the 
flush commands (imagine flushing the gigabytes in an enterprise array on 
each transaction commit), others might return an error on the flush 
command itself (which should be handled correctly).

I don't think that you need to add support if the HBA has a battery 
backed cache and the target drives have disabled write caches...

Ric

>   
>> _______________________________________________
>> Ext3-users mailing list
>> Ext3-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/ext3-users
>>