barrier and commit options?

Miller, Mike (OS Dev) Mike.Miller at
Fri Jan 30 15:56:33 UTC 2009

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.

-- mikem

> _______________________________________________
> Ext3-users mailing list
> Ext3-users at

More information about the Ext3-users mailing list