PRAMFS: Persistent & Protected RAM Filesystem

[phoronix]

Phoronix: PRAMFS: Persistent & Protected RAM Filesystem

Patches on Sunday were published for the Linux kernel that provide PRAMFS, a persistent, non-volatile RAM-based file-system...

http://www.phoronix.com/vr.php?view=MTExNzM

[rxonda]

What about SSD powered rigs?

Is this new fs will boost up SSD rigs?

[Ferdinand]

I still think it is a good idea to have a read write cache in separate DDR3 memory. Use a small flywheel to power it in the case there is a power outage. You could populate it with low voltage 16GB memory of any speed. This would be a cache between the harddisk controllers and the cpu. Such a device would read and write at multiple GB's per second(bursts). This could slowly be synced with the harddisk.

I would like to hear your thoughts.

[huhn_m]

we already have that, it's called buffer cache.

I honestly don't see the benefit in this new fs. It is smaller than a normal buffered fs and less dynamic in what parts are kept in ram (because all of it is).

The only use, as michael wrote in his post, might be write-often embedded systems.

[Ferdinand]

we already have that, it's called buffer cache.

I honestly don't see the benefit in this new fs. It is smaller than a normal buffered fs and less dynamic in what parts are kept in ram (because all of it is).

The only use, as michael wrote in his post, might be write-often embedded systems.

AFAIK buffer cache empties on reboots and crashes. Also it doesn't cache writes. We have all seen what an ssd can do for your system. Now think what it would mean if disk reads or writes of less than 8GB would go at 8GB/s.

[huhn_m]

thats right. as long as you can cope with the small size.

Of course buffer cache is emptied on reboot as you wrote, so it will be faster directly after boot, but less adaptive than the caches.
But writes are also cached. Everything is basically cached and only written back when the kernel sees fit (according to the IO scheduler I think).

So it is basically a "pramfs" for the most or most recently used data.

It has pros and cons but I think the cons (size) outweigh the pros on a traditional system. Your Desktop is slow because it has to load tons of libs, when an application is started. This is better on SSDs where seek times are smaller. While these things would also benefit of the PRAMFS you would need potentially all libs in there and the binaries probably as well. On my small system thats 800MB already. Then you would need the local caches (of your browser, the thumbnail cache etc) to have the same effects as a ssd and so on. I don't think this is the approach for the desktop.

[Ferdinand]

thats right. as long as you can cope with the small size.

Of course buffer cache is emptied on reboot as you wrote, so it will be faster directly after boot, but less adaptive than the caches.
But writes are also cached. Everything is basically cached and only written back when the kernel sees fit (according to the IO scheduler I think).

So it is basically a "pramfs" for the most or most recently used data.

It has pros and cons but I think the cons (size) outweigh the pros on a traditional system. Your Desktop is slow because it has to load tons of libs, when an application is started. This is better on SSDs where seek times are smaller. While these things would also benefit of the PRAMFS you would need potentially all libs in there and the binaries probably as well. On my small system thats 800MB already. Then you would need the local caches (of your browser, the thumbnail cache etc) to have the same effects as a ssd and so on. I don't think this is the approach for the desktop.

I have 16GB of memory in my pc and I would love to use 8GB of that just to have a permanent read write cache of my harddisk. You can spend thousands of dollars on a high end ssd just to get 1GB/s and yet consumers data could easily fit in a 8GB cache that can do 8GB/s.

[huhn_m]

Ok. So obviously this might be something for you.

But you can have this now with some (more or less minor) drawbacks:

Mount the wanted directories you want "fast" as tmpfs in your fstab after backing up their contents (that you would do as well for the pramfs, just not as tmpfs )

Write a cron job that executes rsync and syncs the ramdisk contents to harddisk. This should also be executed on shutdown.
On startup you copy the files into the newly mounted tmpfses.

The only drawback is the manual syncing described above that the pramfs would help you with. So IMHO this is more the job of a userspace tool than a full fledged, kernel mode filesystem.

[Ferdinand]

Ok. So obviously this might be something for you.

But you can have this now with some (more or less minor) drawbacks:

Mount the wanted directories you want "fast" as tmpfs in your fstab after backing up their contents (that you would do as well for the pramfs, just not as tmpfs )

Write a cron job that executes rsync and syncs the ramdisk contents to harddisk. This should also be executed on shutdown.
On startup you copy the files into the newly mounted tmpfses.

The only drawback is the manual syncing described above that the pramfs would help you with. So IMHO this is more the job of a userspace tool than a full fledged, kernel mode filesystem.

Preload would already do what you are suggesting. And I already use it but that still won't give you a fast boot. It will take minutes before the most used data is preloaded. Also this will not give you fast writes.

[huhn_m]

but pramfs will also preload. Because it has to get the stored data from somewhere. I doubt that the effect differs for the two approaches (at least from what I can gather from the article)

btw: wtf?

"PRAMFS is targeted to fast I/O memory, and if the memory is non-volatile, the filesystem will be persistent."

Thats what the site says. So what IS the difference for tmpfs on these devices? You need nv-ram anyways ...