From: Paolo Bonzini <pbonzini@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ric Wheeler <ricwheeler@gmail.com>,
"Black, David" <david.black@emc.com>,
Jeremy Linton <jlinton@tributary.com>,
Ric Wheeler <rwheeler@redhat.com>, Hannes Reinecke <hare@suse.de>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"Martin K. Petersen" <mkp@mkp.net>,
Jeff Moyer <jmoyer@redhat.com>, Tejun Heo <tj@kernel.org>,
Mike Snitzer <snitzer@redhat.com>,
"Elliott, Robert (Server Storage)" <Elliott@hp.com>,
"Knight, Frederick" <Frederick.Knight@netapp.com>
Subject: Re: T10 WCE interpretation in Linux & device level access
Date: Wed, 24 Apr 2013 23:54:21 +0200 [thread overview]
Message-ID: <5178548D.6020805@redhat.com> (raw)
In-Reply-To: <1366837373.1971.28.camel@dabdike>
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"?
Also, this would be in addition to my patch (when tested), right?
Paolo
next prev parent reply other threads:[~2013-04-24 21:54 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 19:41 T10 WCE interpretation in Linux & device level access Ric Wheeler
2013-04-23 20:07 ` James Bottomley
2013-04-23 22:39 ` Jeremy Linton
2013-04-24 5:44 ` Elliott, Robert (Server Storage)
2013-04-24 11:00 ` Ric Wheeler
2013-04-27 16:09 ` James Bottomley
2013-04-24 11:17 ` Paolo Bonzini
2013-04-24 12:07 ` Hannes Reinecke
2013-04-24 12:08 ` Paolo Bonzini
2013-04-24 12:12 ` Hannes Reinecke
2013-04-24 12:23 ` Paolo Bonzini
2013-04-24 12:27 ` Mike Snitzer
2013-04-24 12:27 ` Ric Wheeler
2013-04-24 12:57 ` Paolo Bonzini
2013-04-24 14:35 ` Jeremy Linton
2013-04-24 18:20 ` Black, David
2013-04-24 20:41 ` Ric Wheeler
2013-04-24 21:02 ` James Bottomley
2013-04-24 21:54 ` Paolo Bonzini [this message]
2013-04-24 22:09 ` James Bottomley
2013-04-24 22:36 ` Ric Wheeler
2013-04-24 22:46 ` James Bottomley
2013-04-25 11:35 ` Ric Wheeler
2013-04-25 14:12 ` James Bottomley
2013-04-25 1:32 ` Martin K. Petersen
2013-04-27 6:03 ` Paolo Bonzini
2013-04-24 11:30 ` Hannes Reinecke
2013-04-23 20:28 ` Douglas Gilbert
2013-04-24 15:40 ` Douglas Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5178548D.6020805@redhat.com \
--to=pbonzini@redhat.com \
--cc=Elliott@hp.com \
--cc=Frederick.Knight@netapp.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=david.black@emc.com \
--cc=hare@suse.de \
--cc=jlinton@tributary.com \
--cc=jmoyer@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@mkp.net \
--cc=ricwheeler@gmail.com \
--cc=rwheeler@redhat.com \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).