Supporting filesystems in persistent memory

Posted Sep 4, 2014 18:35 UTC (Thu) by markusw (guest, #53024)
In reply to: Supporting filesystems in persistent memory by dgc
Parent article: Supporting filesystems in persistent memory

Granted, I omitted the cacheline size. However, the CPU/MMU happily writes individual cachelines to RAM, despite the VM mapping. I'd also argue that the VM page size barely has an influence on the block size of block devices (otherwise, moving from 512B to 4K sectors would have a noticeable impact; let alone the 2M pages).

To me, the "architectural structure" of a NAND based SSD looks very different from magnetic tapes or disks. It's not that we're lucky to not have to modify our designs because the architecture didn't change. It did. A lot. It's our existing designs that force new technology to immitate something we already have, know and designed for.

I certainly agree that it makes sense to use a file-system that was designed with block devices in mind on anything that resembles a block device. It also seems logical that a filesystem not designed for persistency is an utterly bad fit for NVM. And I can imagine getting quick results with a block device based filesystem on NVM. However, if the NVM device can write individual cachelines (and assuming that's not a lot less efficient than 4K block writes, as I would expect from something I connect to the CPU's memory bus), then a filesystem that assumes it needs to write a sector at a time doesn't feel like the right thing to me.

I don't follow your last argument, either. By definition, volatile information doesn't need to persist across a reboot (unlike an FS on NVM, where your argument holds). If NVM would be cheaper than RAM (at the same capacity and latency), you could simply wipe the device (or relevant portions) upon boot to make it behave like RAM.

However, persistence clearly is an additional feature (when compared to RAM). And I bet we continue to have to pay for that. Either with higher latency or higher price.

Markus

Supporting filesystems in persistent memory

Posted Sep 11, 2014 14:45 UTC (Thu) by kevinm (guest, #69913) [Link]

> However, if the NVM device can write individual cachelines (and assuming that's not a lot less efficient than 4K block writes, as I would expect from something I connect to the CPU's memory bus), then a filesystem that assumes it needs to write a sector at a time doesn't feel like the right thing to me.

That's the point of this DAX work, though - when a filesystem supports direct access, the NVM page *is* the page cache page, and at least for file data there's no writing of sectors at all. A write() of 64 bytes will just result in a 64 byte copy_from_user() directly into the NVM.

(The sticking point is that there will still be an in-memory inode structure and an "on-disk" inode structure stored in the NVM, which will probably mean that the entire NVM copy of the inode gets rewritten whenever an attribute like mtime changes).

Supporting filesystems in persistent memory

Posted Sep 20, 2014 22:13 UTC (Sat) by Lennie (subscriber, #49641) [Link] (1 responses)

"If NVM would be cheaper than RAM .., you could simply wipe the device .. upon boot to make it behave like RAM."

The security community is going to laugh at that if you don't have some kind of policy around not writing private keys to NVM. Which will probably not work. Existing applications don't have any concept of different kinds of memory for holding keys so you'd need to modify all of them ?

The security community isn't even happy with keeping keys in RAM as it is. As a simple can of compressed air can prevent your RAM from being wiped already:

http://en.wikipedia.org/wiki/Cold_boot_attack

Supporting filesystems in persistent memory

Posted Sep 22, 2014 20:09 UTC (Mon) by zlynx (guest, #2285) [Link]

> The security community isn't even happy with keeping keys in RAM as it is.

And then the invent things like TPM chips and "secure element" chips. But then they make them so impossible to use that programmers have no choice except to store encryption keys in RAM.