PMFS and Linux 4.0 DAX

Matthew Wilcox willy at linux.intel.com
Fri Apr 24 07:35:59 PDT 2015


On Fri, Apr 24, 2015 at 02:25:09PM +0100, Jack Harvard wrote:
> I'm just trying to understand more, not trying to disagree but trying
> to be convinced. As you said there's no big win to be had by enabling
> byte access to filesystem metadata that are stored on the persistent
> memory, presumably you have measured such across a range of workloads?
> including file utilities such as mv, rename, touch etc which do only
> meta data manipulations as mentioned in the PMFS paper.

I said "We don't think", not "we measured" :-)  The customers we've been
talking to about persistent memory talk about queries per second to a
database, not about renaming millions of files per second.

If there's someone out there who cares about the performance of metadata
operations, please speak up (even better if you provide a benchmark).
Bear in mind that no production quality filesystem can be as fast as pmfs
at metadata operations because pmfs cheats by avoiding necessary locking.

> I suppose the persistency support still needs to be built on top of
> the DAX, or does the file APIs like read() and write() have been
> rewritten with such, which would need to support different
> architectures if ext4 already worked with a few architectures.

The DAX code does not currently execute the PCOMMIT instruction.  That's
OK because there's aren't any released CPUs that implement the PCOMMIT
instruction, so it's no worse than the XIP code was.  We should have
(cross-architecture) patches to add PCOMMIT within the next few weeks.




More information about the Linux-pmfs mailing list