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

[Marco]

Pavel Machek wrote:
>>> Why is an entire filesystem needed, instead of simply a block driver
>>> if the ramdisk driver cannot be used?
>>>
>> >From documentation:
>>
>> "A relatively straight-forward solution is to write a simple block
>> driver for the non-volatile RAM, and mount over it any disk-based
>> filesystem such as ext2/ext3, reiserfs, etc.
>>
>> But the disk-based fs over non-volatile RAM block driver approach has
>> some drawbacks:
>>
>> 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

In addition I can do an example of "compact" information: ext2 uses
directory entry objects ("dentries") to associate file names to inodes,
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.

>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.

I hope I've answered to your question.

Regards,

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/