On Fri, Aug 24, 2012 at 06:10:21PM +0000, Michael van Elst wrote: > bou...@antioche.eu.org (Manuel Bouyer) writes: > > >How do you think this should be handled ? have a sysctl to control > >mfi's behavior per-controller (eventually with default depending on BBU > >status), or have a vfs.wapbl.flush_disk_cache per mount-point > >(with a mount option maybe) ? > > WAPBL really needs the cache flush operations, so while disabling it > for debugging is probably useful, I don't think that we need to > offer finer controls. > > You can ignore the flush operation when the controller has a working BBU > except for shutdown/suspend.
But the mfi(4) driver doesn't know if the request is from a WAPBL operation, or something else. > > For controllers without BBU, there should be a limit on how much write data > it is allowed to keep dirty in the cache, so that a flush can finish > quickly. But this is hard to track down. The controller doesn't notify when he decides to flush some data. > The standard drivers always turn off write caching when the BBU > is not working. No, this is something the user can control directly in firmware, at last with mfi(4) controllers. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --