On 04/24/2013 06:46 PM, James Bottomley wrote:
On Wed, 2013-04-24 at 18:36 -0400, Ric Wheeler wrote:
On 04/24/2013 06:09 PM, James Bottomley wrote:
On Wed, 2013-04-24 at 23:54 +0200, Paolo Bonzini wrote:
Il 24/04/2013 23:02, James Bottomley ha scritto:
That just leaves us with random standards behaviour. Lets permit the
deterministic thing instead for the distros. It kills two birds with
one stone because we can set WCE for the stupid UAS devices that clear
it wrongly as well.
For those who don't read code well, you add a temporary prefix to the
cache set in
echo xxx > /sys/class/scsi_disk/<disk>/cache_type
and it will set the flags for the lifetime of the current kernel, but
won't try to do a mode select to make them permanent.
Having the knob is useful indeed. I don't like the "temporary" name
though, because "temporary write-through" doesn't sound like it can eat
data on a power loss. What about "force" or "assume"?
I'm fairly ambivalent, except not force. The default behaviour is to do
the mode select, so force seems to imply that as well, except it won't.
I don't see a difference between assume and temporary.
Also, this would be in addition to my patch (when tested), right?
Not really ... given T10s deprecation I don't think we want to touch
anything to do with SYNC_NV because it just adds to the uncertainty
about what will actually happen. Giving the ability to control WCE (and
RCD) fixes all the problems raised so far.
Why are we turning off the RCD bit in this? Not sure it matters, but we only
should care about WCE (and the dirty write cache data)?
Well, it's in the code. Cache policy is a combination of those two
bits. The cache type takes a cache policy string, ergo it must update
both. We don't do anything with it because having a write back cache
and no cache at all is transparent to us.
James
It was pointed out to me that RCD is "Read Cache Disable" so by setting it to
zero, we are enabling the read cache (not that we ever look at this bit or send
it down). The WCE bit is "write cache enable" so the polarity of the bits is
inverted.
Should be fine regardless :)
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
