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 -- 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
