Description
The file and crucible block backends essentially assume they'll only be used with a block device operating in writeback mode today. Completed Write
operations make no guarantees about whether they've been persisted to the underlying storage with an expectation that subsequent Flush
operations will be sent:
current backend behaviour
file
The file handle used to service requests is not opened with any sync flags (e.g. O_SYNC
, O_DSYNC
) but Flush
commands will be handled via calls to fdatasync
.
crucible
Crucible currently supports both flush and non-synchronous writes. It may also sometimes initiate Flush
without a corresponding guest/device request but need to double check.
proposed
Today, the nvme
device advertises that volatile write cache is enabled. virtio-block
does not expose the similar flush capability (and with the backends assuming writeback it means it's susceptible to data loss; see #492).
Both nvme
and virtio-block
allow negotiating whether or not such modes are enabled but there's no way for the block devices to communicate that to the backends.
file
The file backend should be able to update its file handle to add/remove O_DSYNC
via F_GETFL
/F_SETFL
.
crucible
Either crucible upstairs or the crucible backends should offer some type of combined Write+Flush
operation to use with writeback disabled and the usual Write
/ Flush
commands otherwise.