Christoph Hellwig, on 07/30/2010 12:11 AM 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.
There are also SCSI devices which keep changed settings only until the
next reset/restart. (The devices might be shared, so other initiators
can at any time reset them.)
So, to make the changed settings to not be resetted, there must be a
procedure which would catch the corresponding notification event (RESET
Unit Attention for SCSI) and set the resetted settings back in the
desired value.
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
