In case a platform doesn't provide explicit flush-hints but provides an explicit flush callback, then nvdimm_has_flush() still returns '0' indicating that writes do not require flushing. This happens on PPC64 with patch at [1] applied, where 'deep_flush' of a region was denied even though an explicit flush function was provided.
Similar problem is also seen with virtio-pmem where the 'deep_flush' sysfs attribute is not visible as in absence of any registered nvdimm, 'nd_region->ndr_mappings == 0'.
In case of async flush callback, do we still need "deep_flush" ?
'deep_flush' in libnvdimm (specifically 'deep_flush_store()') anyways resorts to calling 'async_flush' callback if its defined. Which makes sense to me since in absence of eADR, 'echo 1 > deep_flush' would ensure that writes to pmem are now durable even if there is a sudden power loss before cpu caches are flushed.
On non-nfit architectures the 'async_flush' callback should provide such a guarantee, which can be triggered by user-space writing to the 'deep_flush' sysfs attr.
In absence of 'deep_flush' sysfs attr not sure how else can user-space forcibly trigger async_flush callback for dev-dax char devices.
O.k. that means for filesystem DAX deep_flush is alternative to fsync/msync call.
I still have to dig deeper to understand more about "QUEUE_FLAG_FUA" flag & why I was seeing REQ_FUA with virtio-pmem when doing fsync if its not enabled in function "blk_queue_write_cache". But this is for my understanding.
Overall patch looks good to me and it looks to solve (not tested though) the warning for virtio-pmem as well.
Reviewed-by: Pankaj Gupta pankaj.gupta@ionos.com
Thanks, Pankaj