5 ms·
That's about the same durability as Intel Optane had, so the first thing it could be would be to replace Optane where it has been used. Optane did inspire a lo
by Findecanor 3y ago
That's about the same durability as Intel Optane had, so the first thing it could be would be to replace Optane where it has been used.
Optane did inspire a lot of R&D into persistent data structures, databases and file systems that started to challenge the traditional model of local memory and persistent storage.
IMHO, a few of those projects were a little bit overoptimistic, and used NVRAM as DRAM without many restrictions. For NVRAM to be viable, I think it still needs to have overprovisioning, wear levelling, memory-protection and transactions, provided by hardware and/or an OS but not necessarily with traditional interfaces. It is mostly a matter of mapping it CoW via a paging scheme instead of directly, and it will still be at near-DRAM speed.
- zozbot234 3y agoThat's basically the equivalent of a Flash Translation Layer, and having it removes the original selling point of making fsync() a no-op. At that point, persistent memory's only advantage over existing non-volatile storage is possibly higher performance.
- Findecanor 3y agoTo hell with fsync(), I'd want a proper commit()! ;) The performance is so high that the assumptions that had led to the old file system interfaces don't apply any more. There is opportunity for something better.
- _a_a_a_ 3y agoSorry, what is commit() here?
- pmontra 3y agoMaybe begin() try { work on several in memory data structures commit() } catch { rollback() } And all those data structures are either collectively updated or not.
- danbruc 3y agoTransactional memory [1], there are existing hardware and software implementations. [1] https://en.wikipedia.org/wiki/Transactional_memory https://en.wikipedia.org/wiki/Transactional_memory
- yencabulator 3y agoNone of which seem to perform well in the real world when you measure anything but CS papers published...
- foobiekr 3y agoThere are software transactional memories for nearly all programming languages. A project I worked on, shipping since the mid 2000s, uses an in memory STM for nearly all operations.
- CoastalCoder 3y agoWhy transactions?
- two_handfuls 3y agoBecause it’s the best way to survive failures (such as loss of power). Transactions allow you to know that all your datastructures are in a consistent state.
- Findecanor 3y agoIt would also enforce that writes happen only when a program explicitly declares that it is necessary. When writes are persistent and cause wear, the consequences of e.g. a common buffer overflow or use-after-free bug can be much higher than if they were not. Even an unoptimised loop that writes to NVRAM could be bad.