barrier and commit options?

[Miller, Mike (OS Dev)]

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