linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux Embedded <linux-embedded@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Tim Bird <tim.bird@am.sony.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 01/16 v5] pramfs: documentation
Date: Mon, 03 Jan 2011 10:54:28 +0100	[thread overview]
Message-ID: <4D219CD4.1070307@gmail.com> (raw)
In-Reply-To: <20110103074526.GA2687@ucw.cz>

Il 03/01/2011 08:45, Pavel Machek ha scritto:
> Hi!
> 
>> +But the disk-based fs over non-volatile RAM block driver approach has
>> +some drawbacks:
>> +
>> +1. Complexity of disk-based fs: disk-based filesystems such as ext2/ext3/ext4
>> +   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
> 
> Yes, and they are also used on 99% of machines out there -> well
> debugged.

I know that you aren't a supporter for this kind of project...do you
mean that the world finishes with ext4? Why do you ask for removing from
mainline logfs, nilfs, btrs and so on? At the end all can use ext4
everywhere and in all situations, other fs are crap. In addition, I
really don't want to replace extN fs or say "my fs is absolute better of
extN", I'm pointing out that a simpler and ad-hoc solution for *this use
case* maybe it's better.

> 
> Is there fsck for pramfs available, for example?
> 

Currently not. First of all there isn't a device sdX to use, I could use
mem but it's not always available when you use strict_devmem option
because the memory region is marked "exclusive" (it's used to avoid to
"play" with that memory region). In addition, since the simplicity and
the scope of this fs I didn't find an use case that justifies writing an
fsck.

>> +   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... how big is overhead of pramfs compared to ext2?

You can find a lot of information on the tech web site page.

> 
> Can pramfs handle powerdown at arbitrary time?
> 

If you are asking for journaling, the answer is currently not. Adding
journaling means a deeply rework and redesing. This effort can be
justified only with high benefits. At the moment for the scope of this
fs I didn't find them. I recall that we are not talking about replace an
fs like ext4 for a desktop rootfs, but only to have a place to write not
sensible and temporary information in an embedded system. There are
other example of this kind as the pmem driver written by Google guys (it
was in the staging tree) or the "persistent store" written by Tony Luck.
The idea here is to provide a classic fs interface to that memory area.

Marco

      reply	other threads:[~2011-01-03  9:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16 17:59 [PATCH 01/16 v5] pramfs: documentation Marco Stornelli
2011-01-03  7:45 ` Pavel Machek
2011-01-03  9:54   ` Marco Stornelli [this message]

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=4D219CD4.1070307@gmail.com \
    --to=marco.stornelli@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tim.bird@am.sony.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).