[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: barrier and commit options?

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?

-- 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,



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]