barrier and commit options?

[Ric Wheeler]

Miller, Mike (OS Dev) wrote:
> Eric wrote:
>   
>> Christian Kujau wrote:
>>     
>>> On Fri, 30 Jan 2009, Nicolas KOWALSKI wrote:
>>>       
>>>> I know I may loose the last 30 seconds of "work" (it's just a home 
>>>> server), but is the filesystem at risk (corruption, whatever, ...) 
>>>> with these mount options ?
>>>>         
>>> No, why would it? If certain mount options would make a filesystem 
>>> prone to corruption I'd consider this a bug.
>>>       
>> Well, that's not exactly true.  Turning off barriers, 
>> depending on your storage, could lead to corruption in some 
>>     
>
> 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,

Regards,

Ric