Skip to content

OpenNVM: new interfaces for non-volatile memory

opennvm.github.io
41 pointsnphase5 comments
On HN

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.