mmap

> 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.

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.