Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush() | Date | Thu, 27 Apr 2017 14:41:08 -0400 |
| |
Dan Williams <dan.j.williams@intel.com> writes:
>> The sentiment is that programs shouldn't have to grovel around in sysfs >> to do stuff related to an open file descriptor or mapping. I don't take >> issue with the name. I do worry that something like 'wpq_drain' may be >> too platform specific, though. The NVM Programming Model specification >> is going to call this "deep flush", so maybe that will give you >> some inspiration if you do want to change the name. > > I'll change to "deep_flush", and I quibble that this is related to a > single open file descriptor or mapping. It really is a "region flush" > for giving extra protection for global metadata, but the persistence > of individual fds or mappings is handled by ADR. I think an ioctl > might give the false impression that every time you flush a cacheline > to persistence you need to call the ioctl.
fsync, for example, may affect more than one fd--all data in the drive write cache will be flushed. I don't see how this is so different. I think a sysfs file is awkward because it requires an application to chase down the correct file in the sysfs hierarchy. If the application already has an open fd or a mapping, it should be able to operate on that.
As for confusion on when to use the interface, I think that's inevitable no matter how it's implemented. We're introducing a flush type that has never been exposed before, and we're not giving any information on how likely an ADR failure is, or how expensive this flush will be.
Cheers, Jeff
| |