Christoph Hellwig wrote: > On Thu, Jul 29, 2010 at 03:07:17PM -0500, James Bottomley wrote: > > There's lies, damned lies and benchmarks .. but what I was thinking is > > could we just do the right thing? SCSI exposes (in sd) the interfaces > > to change the cache setting, so if the customer *doesn't* specify > > barriers on mount, could we just flip the device to write through it > > would be more performant in most use cases. > > We could for SCSI and ATA, but probably not easily for other kind of > storage. Except that it's not that simple as we have partitions and > volume managers inbetween - different filesystems sitting on the same > device might have very different ideas of what they want. > > For SCSI we can at least permanently disable the cache, but ATA devices > keep coming up again with the volatile write cache enabled after a > reboot, or even worse a suspend to ram / resume cycle. The latter is > what keeps me from just disabling the volatile cache on my laptop, > despite that option giving significanly better performance for typical > kernel developer workloads. I have workloads where enabling volatile write cache + barriers is much faster than disabling the cache. It is admittedly a 2.4.ancient kernel and PATA on an embedded system, but still, it's enough of a difference (about 3x speedup for large file writes) that it was worth porting SuSE's barrier patches to that kernel so that I could enable the write cache to get a huge speedup while remaining powerfail safe with ext3. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
