mmap [LWN.net]

mmap

Posted Apr 20, 2013 14:56 UTC (Sat) by mjw (subscriber, #16740)
Parent article: LFCS: Preparing Linux for nonvolatile memory devices

> Ric mentioned that the venerable mmap() interface will need to be looked at carefully and "might not be salvageable."

Does anybody have a reference with some more background on why mmap() might not be salvageable?

to post comments

mmap

Posted Apr 20, 2013 20:31 UTC (Sat) by intgr (subscriber, #39733) [Link] (3 responses)

I had the same question. While I trust that Ric Wheeler knows what he's talking about, the whole article (and perhaps the talk) seems much hand-waving about how they need to invent all new APIs and rewrite everything from scratch, with no argumentation.

mmap

Posted Apr 20, 2013 22:47 UTC (Sat) by ricwheeler (subscriber, #4980) [Link]

The talk was about how we will be using existing API's for the near future for pretty much every application - that is why we need to improve latency, tune existing file systems, etc.

There will be some applications that will take advantage of new API's but that is pretty rare (think of how many years it has taken to get to 64 bit applications, multi-threaded, etc :)).

mmap

Posted Apr 21, 2013 2:06 UTC (Sun) by plougher (guest, #21620) [Link]

> While I trust that Ric Wheeler knows what he's talking about, the whole article (and perhaps the talk) seems much hand-waving about how they need to invent all new APIs and rewrite everything from scratch, with no argumentation.

Getting the API right first thing is important. An API is an advertisement/contract which specifies what the subsystem can do efficiently and safely. Choose the API badly and you could be saddled with poor behaviour/supporting difficult to implement features for a long time.

An example of poor API re-use I always think about here is MTD (the Memory Technology Device subsystem covering NAND and NOR flash). MTD was introduced ~2002 as a sub-layer for the JFFS2 flash filesystem. But it also introduced user-level block device access to the underlying NAND/NOR device. This was probably mainly to allow user-level applications to write to the Out of Band data, erase sectors etc, as the block device support was semi-functional, no bad block handling, wear leveling etc. Knowledgeable users of MTD know never to mount a read-write block filesystem (i.e. ext4) via this block device, as it will quickly destroy your flash device... But it is there, and it constantly traps the unwary. In fact "Can I mount ext2 over an MTD device?" is a FAQ on MTD websites.

Beyond that of course is the instances where filesystems become trapped offering API guarantees even if they were never explicitly promised but assumed. The delayed allocation changes in ext4 that caused data loss is an obvious example.

mmap

Posted Apr 22, 2013 18:36 UTC (Mon) by daniel (guest, #3181) [Link]

It is obvious to me that high performance filesystems will be the first to take advantage of these new hardware capabilities transparently. This in no way conflicts with Ric's message. Or putting it another way, why preach to the converted? It's the app people who need to get their thinking caps on, not the usual suspects.

mmap

Posted Apr 21, 2013 0:07 UTC (Sun) by plougher (guest, #21620) [Link]

> Does anybody have a reference with some more background on why mmap() might not be salvageable?

Well an obvious observation is mmap is page oriented and NVM is byte orientated/accessible. If you're layering a filesystem on top of NVM you don't have to align the files to block boundaries or pad, but can pack much more closely... But without block alignment you loose the ability to mmap the file (you can copy to intermediate aligned buffers but this is extra overhead).

CRAMFS-XIP (compressed filesystem with execute in place extensions on NOR flash) has exactly this problem. NOR is memory addressable and thus directly mmapable. However, if you want to execute in place, you can't compress or pack the file in CRAMFS.