Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco Stornelli
Date: Mon Jun 22 2009 - 02:33:39 EST
2009/6/21 Pavel Machek <pavel@xxxxxx>:
>> >> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
>> >> performance on spinning disk media, so they implement features such
>> >> as block groups, which attempts to group inode data into a contiguous
>> >> set of data blocks to minimize disk seeking when accessing files. For
>> >> RAM there is no such concern; a file's data blocks can be scattered
>> >> throughout the media with no access speed penalty at all. So block
>> >> groups in a filesystem mounted over RAM just adds unnecessary
>> >> complexity. A better approach is to use a filesystem specifically
>> >> tailored to RAM media which does away with these disk-based features.
>> >> This increases the efficient use of space on the media, i.e. more
>> >> space is dedicated to actual file data storage and less to meta-data
>> >> needed to maintain that file data.
>> > So... what is the performance difference between ext2 and your new
>> > filesystem?
>> About the "space" you can read a detailed documentation on the site:
> I do not see any numbers there. Do you think you can save significant
> memory when storing for example kernel source trees?
There aren't benchmark, but I pointed it out because if you know ext2
you can do a comparison.
>> In addition I can do an example of "compact" information: ext2 uses
>> directory entry objects ("dentries") to associate file names to
> I'm not sure that on-disk directory entry == dentry.
>> and these dentries are located in data blocks owned by the parent
>> directory. In pramfs, directory inode's do not need to own any data
>> blocks, because all dentry information is contained within the inode's
> How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself because you must consider the
special goal of this fs.
>> >From performance point of view:
>> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
>> results to compare the performance with and without XIP in a real
>> embedded environment with bonnie++. You could use it as reference point.
> Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance
> better than ext2?
> Wait... those numbers you pointed me... claim to be as slow as
> 13MB/sec. That's very very bad. My harddrive is faster than that.
As I said I did the test in a real embedded environment so to have
comparable result you should use the same environmente with the same
tools, with the same workload and so on.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/