Il 25/04/2013 03:32, Martin K. Petersen ha scritto:
I'm ok with your patch. And a strong believer in not altering the
SYNCHRONIZE CACHE behavior that's been rigorously tested in the field by
adding SYNC_NV to the mix.
SYNC_NV is absolutely necessary for targets that (a) have both volatile
and
On Wed, 2013-04-24 at 05:44 +, Elliott, Robert (Server Storage)
wrote:
If the writeback cache is enabled (per the WCE bit in the Caching mode page),
prudent software uses the FUA bit in WRITE commands when writing metadata
and/or sends the SYNCHRONIZE CACHE command at important checkpoints
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
On Thu, 2013-04-25 at 07:35 -0400, Ric Wheeler wrote:
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
Wheeler; linux-scsi@vger.kernel.org; Martin K. Petersen; Jeff Moyer;
Tejun Heo; Mike Snitzer; dgilb...@interlog.com
Subject: Re: T10 WCE interpretation in Linux device level access
On 4/23/2013 3:07 PM, James Bottomley wrote:
I bet they don't; they probably obey the spec. There's a SYNC_NV bit
which
Il 23/04/2013 22:07, James Bottomley ha scritto:
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
For many years, we have used WCE as an indication that a device has a
volatile
write cache (not just a write cache) and used this as a trigger to send down
SYNCHRONIZE_CACHE commands as
On 04/23/2013 10:07 PM, James Bottomley wrote:
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
For many years, we have used WCE as an indication that a device has a
volatile
write cache (not just a write cache) and used this as a trigger to send down
SYNCHRONIZE_CACHE commands as
Il 24/04/2013 14:07, Hannes Reinecke ha scritto:
On 04/24/2013 01:17 PM, Paolo Bonzini wrote:
Il 23/04/2013 22:07, James Bottomley ha scritto:
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
For many years, we have used WCE as an indication that a device has a
volatile
write cache
On 04/24/2013 02:08 PM, Paolo Bonzini wrote:
Il 24/04/2013 14:07, Hannes Reinecke ha scritto:
On 04/24/2013 01:17 PM, Paolo Bonzini wrote:
Il 23/04/2013 22:07, James Bottomley ha scritto:
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
For many years, we have used WCE as an indication
Il 24/04/2013 14:12, Hannes Reinecke ha scritto:
On 04/24/2013 02:08 PM, Paolo Bonzini wrote:
Il 24/04/2013 14:07, Hannes Reinecke ha scritto:
On 04/24/2013 01:17 PM, Paolo Bonzini wrote:
Il 23/04/2013 22:07, James Bottomley ha scritto:
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
On 04/24/2013 08:08 AM, Paolo Bonzini wrote:
Il 24/04/2013 14:07, Hannes Reinecke ha scritto:
On 04/24/2013 01:17 PM, Paolo Bonzini wrote:
Il 23/04/2013 22:07, James Bottomley ha scritto:
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
For many years, we have used WCE as an indication
Il 24/04/2013 14:27, Ric Wheeler ha scritto:
The point is to _avoid_ hitting the disk. :)
The point is to have a crash-proof version of the data acknowledged by
the target device while letting data sit in volatile state as long as
possible. To be even clearer, we would love to do this for a
On 4/24/2013 7:57 AM, Paolo Bonzini wrote:
If the device can promise this, we don't care (and don't know) how it
manages that promise. It can leave the data on battery backed DRAM, can
archive it to flash or any other scheme that works.
That's exactly the point of SYNC_NV=1.
Well
On 13-04-23 03:41 PM, Ric Wheeler wrote:
For many years, we have used WCE as an indication that a device has a volatile
write cache (not just a write cache) and used this as a trigger to send down
SYNCHRONIZE_CACHE commands as needed.
Some arrays with non-volatile cache seem to have WCE set
;
Martin K. Petersen; Jeff Moyer; Tejun Heo; Mike Snitzer; Black, David;
Elliott, Robert (Server Storage); Knight, Frederick
Subject: Re: T10 WCE interpretation in Linux device level access
On 4/24/2013 7:57 AM, Paolo Bonzini wrote:
If the device can promise this, we don't care (and don't know
On 04/24/2013 02:20 PM, Black, David wrote:
Jeremy,
It looks like, you, Paolo and Ric have hit the nail on the head here - this is
a nice summary, IMHO:
On 4/24/2013 7:57 AM, Paolo Bonzini wrote:
If the device can promise this, we don't care (and don't know) how it
manages that promise. It
On Wed, 2013-04-24 at 16:41 -0400, Ric Wheeler wrote:
On 04/24/2013 02:20 PM, Black, David wrote:
Jeremy,
It looks like, you, Paolo and Ric have hit the nail on the head here - this
is
a nice summary, IMHO:
On 4/24/2013 7:57 AM, Paolo Bonzini wrote:
If the device can promise
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
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
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
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
James == James Bottomley james.bottom...@hansenpartnership.com writes:
James I'm fairly ambivalent, except not force. The default behaviour
James is to do the mode select, so force seems to imply that as well,
James except it won't. I don't see a difference between assume and
James temporary.
For many years, we have used WCE as an indication that a device has a volatile
write cache (not just a write cache) and used this as a trigger to send down
SYNCHRONIZE_CACHE commands as needed.
Some arrays with non-volatile cache seem to have WCE set and simply ignore the
command.
Some
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote:
For many years, we have used WCE as an indication that a device has a
volatile
write cache (not just a write cache) and used this as a trigger to send down
SYNCHRONIZE_CACHE commands as needed.
Some arrays with non-volatile cache seem
On 13-04-23 03:41 PM, Ric Wheeler wrote:
For many years, we have used WCE as an indication that a device has a volatile
write cache (not just a write cache) and used this as a trigger to send down
SYNCHRONIZE_CACHE commands as needed.
Some arrays with non-volatile cache seem to have WCE set
On 4/23/2013 3:07 PM, James Bottomley wrote:
I bet they don't; they probably obey the spec. There's a SYNC_NV bit
which if unset (which it is in our implementation) means only sync your
non-NV cache. For a device with all NV, that equates to nop.
Yes, linux leaves the SYNC_NV bit
...@vger.kernel.org] On Behalf Of Jeremy Linton
Sent: Tuesday, April 23, 2013 5:40 PM
To: James Bottomley
Cc: Ric Wheeler; linux-scsi@vger.kernel.org; Martin K. Petersen; Jeff Moyer;
Tejun Heo; Mike Snitzer; dgilb...@interlog.com
Subject: Re: T10 WCE interpretation in Linux device level access
On 4/23
27 matches
Mail list logo
