barrier and commit options?
Ric Wheeler
rwheeler at redhat.com
Fri Jan 30 15:40:14 UTC 2009
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
More information about the Ext3-users
mailing list