Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

[Marco Stornelli]

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:
>>
>> http://pramfs.sourceforge.net/pramfs-spec.html
>
> 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
>> inodes,
>
> 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
>> themselves.
>
> 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.
>                                                                        Pavel
>

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.

Marco
--
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/