Opinion: On pramfs and RAM based Linux file systems
A few days ago I received the latest issue of Linux Journal Magazine. I must admit that one of the sections I look forward to reading is diff -u. This section summarizes the latest updates and discussions of the Linux kernel development community. It becomes much easier to read a summary as opposed to signing up for the mailing list because you will just get bombarded with e-mails which can be overwhelming the majority of the time.
While reading I came across a Montavista developed project called pramfs. In summary pramfs is a non-volatile RAM based file system, similar to your ramfs and tmpfs with a few differences to distinguish it from the others and in turn adapted for an embedded environment. Two obvious differences are that it is persistent like a traditional disk-based file system and does not reside in volatile DRAM. Pramfs is not new. It was originally announced back in 2004. It is designed to be a simplified file system that does not carry the same weight of the journal-based file systems.
Apparently there had been some problems with the patch being merged into the Linux kernel for a number of reasons. (1) Montavista was attempting to patent some of the concepts and algorithms used in the file system (in 2004) and (2) even after the dropped the idea of patenting their code, there was some discussion on the redundancy of having yet another file system implemented into the Linux kernel (in 2009). What that means, is that the Linux kernel already has two commonly used RAM file systems and a large number of other file systems. So why was there a need to write another one? Why couldn’t Montavista patch already existing code? (3) It is also not a full featured file system in that it does not support symbolic links.
I agree with this logic. Please do not misunderstand me. Montavista is a very respectable company that has done an excellent job in supporting embedded Linux. I am also glad to see them contribute to the kernel and in turn the community. But truth be told, tmpfs was build on top of the ramfs code. Why couldn’t pramfs follow the same course of development. The GPL makes it easy to not have to re-invent the wheel.
The two most noteworthy goals achieved for pramfs (1) is to work with NVRAM and (2) provide and interface that does not utilize the kernel page caching mechanism. By utilizing the DIRECTIO flag available in the 2.6 kernel, Montavista claims that I/O performance is increased significantly to an already high performing interface. Pramfs also allows the user to specify regions of memory for file system usage.
mount -t pramfs -o physaddr=0x1e000000,init=0x2000000 none /mnt/pramfs |
With it working in non-volatile memory, the data contents will remain intact even after an expected/unexpected power cycle.
This concept got me thinking a bit. How difficult would it be to add some of these features in Ramfs? Ramfs offer some similar functionality as in it does not use the kernel’s page cache for file I/O. Tmpfs was designed to offer that functionality along with additional file system control and limitations. Ramfs also has a slightly similar general file system layout. Sure a few structures and routines need to be redefined but that isn’t a big deal in the grand scheme of things.
I mention this in the light of some of the latest headlines circulating through the internet regarding Linux Torvalds’ comments on the kernel being bloated. Does the kernel leave room for additional “bloat” or would it be wiser to add on top of current features/functionality? I would love to read some of your opinions.
For more blog posts relating to RAM-based file systems and RAM Disk device drivers, you can find them posted here, here and here.
You should pose this question to the Meld Embedded Linux community and see what response(s) you get from MontaVista and others http://meld.mvista.com
- Troy
Comment by Troy Kitch — 13. October 2009 @ 13:45
Troy,
Thank you for the suggestion. I am thinking that I may do that. I will highlight responses here.
Petros
Comment by admin — 14. October 2009 @ 13:25
Hi,
I’m the lead maintainer of pramfs. First of all Montavista doesn’t support anymore the project (at least in a public way).
> It is also not a full featured file system in that it does not support symbolic links.
No it’s not true.
You wondered why a new fs instead of using Ramfs? Read pramfs.sourceforge.net the technical details.
Marco
Comment by Marco — 20. October 2009 @ 11:24
Marco,
Thank you for your reply. And thank you for some of the clarification. Although I am a bit surprised that a log-structured layout was not utilized instead. We are talking of high performing memory speeds here, so either way you are going to get good results. I am thinking more from a simplistic point of view. I am imagining an environment where storage space is somewhat limited. Traditionally, components that write/read to/from NVRAM are not large and it is my personal opinion that the design layout of pramfs seems to take more space than necessary (http://pramfs.sourceforge.net/tech.html#PRAMFS_Special_Filesystem). I understand why you have a copy of the initial superblock, but the size of the inode table and block bitmap will vary dependant on the size of the overall memory region. What specifically comes to my mind as something that may be more ideal is a layout similar to JFFS2.
I hope I am not offending you with my comments. Please understand it is not my intent to.
Comment by admin — 21. October 2009 @ 14:09
>Traditionally, components that write/read to/from NVRAM are not large and it is my personal >opinion that the design layout of pramfs seems to take more space than necessary >(http://pramfs.sourceforge.net/tech.html#PRAMFS_Special_Filesystem). I understand why you have >a copy of the initial superblock, but the size of the inode table and block bitmap will vary >dependant on the size of the overall memory region. What specifically comes to my mind as >something that may be more ideal is a layout similar to JFFS2.
Pramfs can be configured via some parameters about that: you can specify with bs option the block size (512, 1024, 2048, 4096). with bpi option the bytes per inode ratio, i.e. for every N bytes in the filesystem, an inode will be created. This behaves the same as the “-i” option to mke2fs; with N option you can specify the number of inodes to allocate in the inode table. If the option is not specified, the bytes-per-inode ratio is used the calculate the number of inodes. If neither the N or bpi options are specified, the default behavior is to reserve 5% of the total space in the filesystem for the inode table. I think “the right fs for right environment”. JFFS2 is designed for flash device and there are other problems in that specific context. Pramfs is designed to be space efficient and to have structures “packed”. For this Pramfs doesn’t support hard link, directory entry information, such as file names and owning inode, are contained within the inodes themselves.
>I hope I am not offending you with my comments.
No problem.
Regards,
Marco
Comment by Marco — 22. October 2009 @ 11:46
Marco,
Again, thank you for the clarification.
Comment by admin — 26. October 2009 @ 07:14
Hello,
Thanks for the great article and your comments Marco. Is there currently a replacement in the later kernels that support the persistent capabilities available through PRAMFS? In my embedded environment, I’ve tried ramfs and tmpfs and both destroy data (or at least filesystem structures) on remount. ie - mount fs (as ramfs or tmpfs); write data; umount/mount - no data.
Thanks,
Joe
Comment by Joe — 5. November 2009 @ 08:36
Joe,
You can always patch the latest build of the pramfs code (http://sourceforge.net/projects/pramfs/) into the kernel you are using. It looks like the naming convention mirrors the kernel supported. That is, as of this comment the latest pramfs patch is labeled for the 2.6.30 Linux kernel.
If this does not seem possible, have you explored methods to rsync the RAM based block device? That is, find a method or create a daemon process to rsync and update any changes committed. For instance if I wish to do an initial rsync from source to destination I would use the following command:
# sudo rsync -av <source> <destination>
If there are any updates to the source, I can invoke rsync with the –delete command and it will append/remove only the files that have changed.
# sudo rsync -av –delete <source> <destination>
When the system is taken down and rebooted, a startup script can rsync the destination into the freshly initialized ramfs/tmpfs mount point.
Comment by admin — 5. November 2009 @ 09:41
rsync is not an option in our system. I am attempting the patch now….
Thanks!
Comment by Joe — 6. November 2009 @ 11:49
Joe, there isn’t anything similar in the kernel in this moment. If you have any problems with pramfs I suggest you to write in the right place, i.e. the pramfs ML.
Comment by Marco — 29. November 2009 @ 03:34