Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()
Dan Williams <dan.j.williams(a)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