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

Re: barrier and commit options?



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 redhat com
https://www.redhat.com/mailman/listinfo/ext3-users


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