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 > > _______________________________________________ > Ext3-users mailing list > Ext3-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/ext3-users > _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
