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 needed. >> >> Some arrays with non-volatile cache seem to have WCE set and simply ignore >> the >> command. > > 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.
Isn't it the other way round? SYNC_NV = 0 means "sync all your caches to the medium", and it's what we do. SYNC_NV = 1 means "sync volatile to non-volatile", and it's what Ric wants. So we should set SYNC_NV=1 if NV_SUP is set, perhaps only if the medium is non-removable just to err on the safe side. Ric, can you check what your arrays set in VPD page 0x86 byte 6 bit 1? Paolo >> Some arrays with non-volatile cache seem to not set WCE. >> >> Others arrays with non-volatile cache - our problem arrays - set WCE and do >> something horrible and slow when sent the SYNCHRONIZE_CACHE commands. > > These arrays sound to be out of spec, so we should probably just > blacklist them. > >> Note that for file systems, you can override this behavior by mounting with >> our >> barriers disabled (mount -o nobarrier .....). There is currently no way do >> disable this for anything using the device directly, not through the file >> system. >> >> Some applications run against block devices - not through a file system - >> and >> want not to slow to a crawl when they have an array in my problem set. >> >> Giving them a hook to ignore WCE seems to be a hack, but one that would >> resolve >> issues with users who won't want to wait months (years?) for us to convince >> the >> array vendors. >> >> Is this a hook worth doing? > > We already have the ability to set the cache type in sysfs. It tries to > do a mode select back to the array, but the USB guys want it for the > reverse problem (write back cache behind bridge declared as write > through). > >> Have we hashed this out in the T10 committee? > > SBC-3 contains everything one could wish for about handling devices with > volatile and NV cache, I thought. > > James > > > -- > 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 > -- 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
