Thanks Pankaj for looking into this patch,
Pankaj Gupta pankaj.gupta.linux@gmail.com writes:
Hi Vaibhav,
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.
<snip>