From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: T10 WCE interpretation in Linux & device level access Date: Wed, 24 Apr 2013 15:46:20 -0700 Message-ID: <1366843580.1971.38.camel@dabdike> References: <5176E3E8.3000809@redhat.com> <1366747622.1939.6.camel@dabdike> <5177BF53.3040305@redhat.com> <5177CAF5.6060506@suse.de> <5177CB23.5090802@redhat.com> <5177CFB6.9070105@redhat.com> <5177D6C2.6080705@redhat.com> <5177EDB5.5000105@tributary.com> <8D3D17ACE214DC429325B2B98F3AE71293F3BBE2@MX15A.corp.emc.com> <5178438F.3010103@gmail.com> <1366837373.1971.28.camel@dabdike> <5178548D.6020805@redhat.com> <1366841383.1971.36.camel@dabdike> <51785E5C.8020204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:58906 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758085Ab3DXWqX (ORCPT ); Wed, 24 Apr 2013 18:46:23 -0400 In-Reply-To: <51785E5C.8020204@redhat.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Ric Wheeler Cc: Paolo Bonzini , Ric Wheeler , "Black, David" , Jeremy Linton , Hannes Reinecke , "linux-scsi@vger.kernel.org" , "Martin K. Petersen" , Jeff Moyer , Tejun Heo , Mike Snitzer , "Elliott, Robert (Server Storage)" , "Knight, Frederick" 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//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