in the product, local volumes will be on U.2 devices which happen to have write caches, but are expected to not report volatile write caches because they also have on-device backups to keep write cache state in the face of power loss. this means that local volumes on such disks do not need to report volatile write caches; Propolis opens a character device for the raw volume and I/Os just go right to the disk. that work comes together in oxidecomputer/omicron#10932.
U.2 devices, like anything else, are fallible. the NVMe spec has a log page that's relevant here: SMART / Health Information Log (Log Identifier 02h). bit 4 describes the volatile memory backup device being failed or not. additionally, NVMe device can have an asynchronous event configuration that requests a notification when that bit is set to 1 by the controller.
if we've set up a VM with a local volume on a disk where we elided the write cache bit, we really should at least have the emulated controller reflect this Critical Warning bit if the underlying hardware has also set it. by hiding it we risk the guest believing everything is fine when in fact it is obligated to flush data out or otherwise report some kind of error condition.
I'm not sure if any guest OS or software actually processes these bits. I don't know if a device that had a backed-up write cache with failed backup medium would start reporting a volatile write cache, or you simply set the SMART bit and hope the guest decides to flush more aggressively. devices with VWC must also allow the OS to disable the write cache, but I could imagine that disks with a backup solution simply do not have a means to disable the write cache in a set-features kind of way. and Propolis at least flagrantly violates the spec by never clearing the VWC bit, if it's set!
relatedly: #698 also talks about asynchronous event configuration for a different critical warning bit (3, for "device is read-only". that's probably relevant here too!)
in the product, local volumes will be on U.2 devices which happen to have write caches, but are expected to not report volatile write caches because they also have on-device backups to keep write cache state in the face of power loss. this means that local volumes on such disks do not need to report volatile write caches; Propolis opens a character device for the raw volume and I/Os just go right to the disk. that work comes together in oxidecomputer/omicron#10932.
U.2 devices, like anything else, are fallible. the NVMe spec has a log page that's relevant here:
SMART / Health Information Log(Log Identifier 02h). bit 4 describes the volatile memory backup device being failed or not. additionally, NVMe device can have an asynchronous event configuration that requests a notification when that bit is set to 1 by the controller.if we've set up a VM with a local volume on a disk where we elided the write cache bit, we really should at least have the emulated controller reflect this Critical Warning bit if the underlying hardware has also set it. by hiding it we risk the guest believing everything is fine when in fact it is obligated to flush data out or otherwise report some kind of error condition.
I'm not sure if any guest OS or software actually processes these bits. I don't know if a device that had a backed-up write cache with failed backup medium would start reporting a volatile write cache, or you simply set the SMART bit and hope the guest decides to flush more aggressively. devices with VWC must also allow the OS to disable the write cache, but I could imagine that disks with a backup solution simply do not have a means to disable the write cache in a
set-featureskind of way. and Propolis at least flagrantly violates the spec by never clearing the VWC bit, if it's set!relatedly: #698 also talks about asynchronous event configuration for a different critical warning bit (3, for "device is read-only". that's probably relevant here too!)