On Thu, Apr 5, 2018 at 1:01 AM, Christoph Hellwig <[email protected]> wrote: > On Thu, Apr 05, 2018 at 12:56:02AM -0700, Dan Williams wrote: >> Yes, I think it is unfortunate that the failure mode is exposed to >> software at all. The problem is that ADR is a platform feature that >> depends on power supply requirements external to the NVDIMM device. An >> SSD is different. It is a self contained system that can arrange for >> the whole device to fail if the internal energy source fails and >> otherwise hide this detail from software. My personal take, a system >> designer that can specify and qualify an entire stack of components >> can certainly opt-out of advertising the flush capability to the OS >> because, like the SSD vendor, they control the integrated solution. A >> platform vendor that allows off the shelf power supplies would in my >> opinion be remiss not to give the OS the option to mitigate the >> quality of some random power supply. It then follow that if the OS has >> the ability to mitigate ADR failure it should be through a common >> interface between fsdax and devdax. > > That means IFF ADR can fail like this we can't treat it as stable > storage and we must not support MAP_SYNC or equivalent device dax > behavior, period.
Makes sense, we won't pursue *sync() support on device-dax it doesn't fit. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
