OpenNVM: new interfaces for non-volatile memory

opennvm.github.io

41 points·nphase··5 comments

Could someone explain to me why we need a special NVM interface vs just using a filesystem on the same medium?

I worked at an embedded system shop for 3 years and this was one of the things that irked me when I worked on code outside of what my team usually worked on. We had a filesystem, accessible with all of the standard C file API... but there was still a lot of stuff being put into this mystical NVM (usually user controlled settings) that then made things like hard resets hairy because even as a developer I wasn't sure what would be wiped when I flashed different software onto the device.

This may have just been bad practice, or a result of carrying over the idea of NVM after filesystems became available. But I don't know why anyone would try to propagate that practice these days.

I don't really understand your question here. NVM is non-volatile memory. Stick a filesystem on it and it's still non-volatile memory.

Do you mean they were writing configuration files directly to a known address in Flash instead of using a filesystem? It's much simpler and less resource-intensive and doesn't require writing and maintaining a driver. There are plenty of cases where direct-writes are better, and plenty of cases where a filesystem is better, and a nice big gray area in between.

Whats the cheapest ssd device that implements this interface that a developer could play around with?

Looks like this is only for FusionIO (at least all the examples are FusionIO only).

Any non-FudionIO SSD that actually support this?

Probably not yet but that could change. PCI flash interfaces are going to be standardised as NVMe.

Reply on news.ycombinator.com