From: Marco <marco.stornelli@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Jamie Lokier <jamie@shareable.org>,
Linux Embedded <linux-embedded@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Daniel Walker <dwalker@soe.ucsc.edu>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Date: Sun, 21 Jun 2009 19:34:32 +0200 [thread overview]
Message-ID: <4A3E6F28.4090404@gmail.com> (raw)
In-Reply-To: <20090621064040.GC1656@ucw.cz>
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
next prev parent reply other threads:[~2009-06-21 17:34 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-13 13:20 [PATCH 00/14] Pramfs: Persistent and protected ram filesystem Marco
2009-06-13 13:41 ` Daniel Walker
2009-06-13 15:59 ` Jamie Lokier
2009-06-14 7:15 ` Marco
2009-06-14 11:08 ` Artem Bityutskiy
2009-06-15 15:51 ` Bryan Henderson
2009-06-15 17:42 ` Marco
2009-06-14 11:46 ` Jamie Lokier
2009-06-14 16:04 ` Marco
2009-06-16 15:07 ` Jamie Lokier
2009-06-16 19:15 ` Marco
2009-06-24 17:41 ` Jamie Lokier
2009-06-25 6:44 ` Marco Stornelli
2009-06-26 11:30 ` Jamie Lokier
2009-06-26 16:56 ` Marco
2009-06-24 14:21 ` Pavel Machek
2009-06-21 6:40 ` Pavel Machek
2009-06-21 17:34 ` Marco [this message]
2009-06-21 20:52 ` Pavel Machek
2009-06-22 6:33 ` Marco Stornelli
2009-06-22 17:20 ` Pavel Machek
2009-06-22 17:31 ` Tim Bird
2009-06-22 17:37 ` Pavel Machek
2009-06-22 18:07 ` Marco
2009-06-22 20:40 ` Henrique de Moraes Holschuh
2009-06-22 20:40 ` Pavel Machek
2009-06-22 21:50 ` Tim Bird
2009-06-22 21:57 ` Pavel Machek
2009-06-22 22:38 ` Pavel Machek
2009-06-22 23:26 ` Chris Friesen
2009-06-23 1:42 ` David VomLehn
2009-06-23 18:07 ` Marco
2009-06-23 18:29 ` Pavel Machek
2009-06-24 17:47 ` Jamie Lokier
2009-06-25 6:32 ` Marco Stornelli
2009-06-22 18:55 ` Tim Bird
2009-06-22 21:02 ` Pavel Machek
2009-06-22 22:02 ` Tim Bird
2009-06-22 18:08 ` Marco
2009-06-15 17:15 ` Tim Bird
2009-06-15 17:44 ` Marco
2009-06-15 17:58 ` Tim Bird
2009-06-17 18:32 ` Chris Friesen
2009-06-18 6:35 ` Marco Stornelli
[not found] <4a4254e2.09c5660a.109d.46f8@mx.google.com>
2009-06-24 16:49 ` Marco
2009-06-24 17:38 ` Marco
2009-06-24 17:59 ` Pavel Machek
2009-06-25 6:30 ` Marco Stornelli
2009-06-28 8:59 ` Pavel Machek
2009-06-28 16:44 ` Marco Stornelli
2009-06-28 17:33 ` Marco Stornelli
2009-07-09 23:42 ` Pavel Machek
2009-06-24 17:46 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A3E6F28.4090404@gmail.com \
--to=marco.stornelli@gmail.com \
--cc=dwalker@soe.ucsc.edu \
--cc=jamie@shareable.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).