Announcement
Collapse
No announcement yet.
PRAMFS: Persistent & Protected RAM Filesystem
Collapse
X
-
Can this be used to offload periodic writes to hdd (such as logs) and then move it to hdd in one dump when powering off the system?
-
Originally posted by TAXI View Posttmpfs is in RAM, RAM needs constant power to store data. If your desktop is powered off the RAM has no power.
pramfs is in NV-RAM. NV-RAM is RAM with a constant power source. An example is the so called CMOS, which is the place where the BIOS stores its settings on desktop machines. That's why a desktop mainboard has a 3.3 V battery...
Leave a comment:
-
Originally posted by huhn_m View Postbut pramfs will also preload. Because it has to get the stored data from somewhere.
"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 ...
pramfs is in NV-RAM. NV-RAM is RAM with a constant power source. An example is the so called CMOS, which is the place where the BIOS stores its settings on desktop machines. That's why a desktop mainboard has a 3.3 V battery...
So while you may have 16 GB RAM you have around 1 MB (maybe less... I think it starts from 16 KB?) NV-RAM, which is still filled up by the BIOS. That's why PRAMFS targets embedded devices...
Leave a comment:
-
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 ...Last edited by huhn_m; 10 June 2012, 03:08 PM.
Leave a comment:
-
Originally posted by huhn_m View PostOk. 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.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by huhn_m View Postthats 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.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by huhn_m View Postwe 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.
Leave a comment:
-
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.
Leave a comment:
Leave a comment: