We have two models of storage - volatile working storage, and things that simulate disk drives. It's not clear what to do with persistent randomly addressable storage at DRAM speed. Having to go through an OS and a file system to access a few bytes kills the performance advantage of such devices. Making the device look like RAM makes it too easy to mess up. We need something in between, probably with processor support to allow controlled access without going through the OS for each access.
The great thing about RAM being volatile is that you can reboot and clean up your mess. With persistent storage, things can go gradually downhill.
Use the MMU to keep the fast non-volatile RAM out of both application and kernel memory, put a traditional RAM disk file system on the fast non-volatile RAM, and let mmap truly map blocks of files into address spaces, instead of demand-paging it in.
That probably is not the best one can do, but it is simple, and may be fairly easy to get ‘right’ if you put the code handling the file system part into a secondary kernel address space. That keeps the part that can mess up the file system’s metadata small.
Coincidentally I noticed some recent patches on linux-kernel:
"BTT is a library that converts a byte-accessible namespace into a disk with atomic sector update semantics (prevents sector tearing on crash or power loss). ... BLK is a driver for NVDIMMs that provide sliding mmio windows to access persistent memory." https://lwn.net/Articles/649588/
I think the only distinction you need to make is memory where transactions make sense (user data), and where they don't (program state).
I can see a scenario where opening a file for writing works just like mmap[0] with MAP_PRIVATE, i.e. you get blockwise copy-on-write, except everything will persist as if everything on your filesystem was under a VCS like git.
I reckon just like volume management, encryption and snapshotting has steadily been folded in to the filesystem, so will the VFS and page cache.
We have two models of storage - volatile working storage, and things that simulate disk drives. It's not clear what to do with persistent randomly addressable storage at DRAM speed. Having to go through an OS and a file system to access a few bytes kills the performance advantage of such devices. Making the device look like RAM makes it too easy to mess up. We need something in between, probably with processor support to allow controlled access without going through the OS for each access.
The great thing about RAM being volatile is that you can reboot and clean up your mess. With persistent storage, things can go gradually downhill.