Announcement

Collapse
No announcement yet.

PRAMFS: Persistent & Protected RAM Filesystem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • maciejus
    replied
    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?

    Leave a comment:


  • JanC
    replied
    Originally posted by TAXI View Post
    tmpfs 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...
    With real NVRAM (e.g. Flash, although currently some new techniques are being developed that will allow NVRAM that is almost as fast as DRAM), there is no need for a battery to keep its contents. The battery on your motherboard is still there for the clock that keeps the time while all or most of the motherboard is powered off though.

    Leave a comment:


  • V10lator
    replied
    Originally posted by huhn_m View Post
    but pramfs will also preload. Because it has to get the stored data from somewhere.
    No it doesn't...
    "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 ...
    tmpfs 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...
    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:


  • huhn_m
    replied
    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:


  • Ferdinand
    replied
    Originally posted by huhn_m View Post
    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.

    Leave a comment:


  • huhn_m
    replied
    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:


  • Ferdinand
    replied
    Originally posted by huhn_m View Post
    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.

    Leave a comment:


  • huhn_m
    replied
    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:


  • Ferdinand
    replied
    Originally posted by huhn_m View Post
    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.

    Leave a comment:


  • huhn_m
    replied
    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:

Working...
X