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 and simply ignore the command. 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.
Do the problematic arrays correctly set the NV_SUP** or V_SUP bits in the Extended Inquiry VPD pages? Does Linux take any notice of those bits? [Guess the answer.] If the problematic arrays correctly set the NV_SUP and Linux sends SYNCHRONIZE_CACHE commands then Linux should be named and shamed.
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? Have we hashed this out in the T10 committee?
There is also a NV_DIS bit in the caching mode page that if supported would allow the NV cache to be disabled. Looks like T10 supplies enough knobs, it is up to the vendor to set them appropriately and Linux to take notice. Doug Gilbert ** What JB called SYNC_NV ... -- 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
