linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Marco <marco.stornelli@gmail.com>
Cc: tim.bird@am.sony.com, 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: Wed, 24 Jun 2009 19:46:57 +0200	[thread overview]
Message-ID: <20090624174657.GA6618@elf.ucw.cz> (raw)
In-Reply-To: <4A425907.2060105@gmail.com>

On Wed 2009-06-24 18:49:11, Marco wrote:
> >> Pavel Machek wrote:
> >>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> >>>> Pavel Machek wrote:
> >>>>>> block of fast non-volatile RAM that need to access data on it using a
> >>>>>> standard filesytem interface."
> >>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
> >>>>> better with ext2.
> >>>> Not if you want the RAM-based filesystem to persist over a kernel
> >>>> invocation.
> >>> Yes, you'll need to code Persistent, RAM-based _block_device_. 
> >> First of all I have to say that I'd like to update the site and make it
> >> clearer but at the moment it's not possible because I'm not the admin
> >> and I've already asked to the sourceforge support to have this possibility.
> >>
> >> About the comments: sincerely I don't understand the comments. We have
> >> *already* a fs that takes care to remap a piace of ram (ram, sram,
> >> nvram, etc.), takes care of caching problems, takes care of write
> > 
> > Well, it looks pramfs design is confused. 13MB/sec shows that caching
> > _is_ useful for pramfs. So...?
> 
> caching problems means to avoid filesystem corruption, so dirty pages in
> the page cache are not allowed to be written back to the backing-store
> RAM. It's clear that there is a performance penalty. This penalty should
> be reduced by the access speed of the RAM, however the performance are
> not important for this special fs as Tim Bird said, so this question is
> not relevant for me. If this issue is not clear enough on the web site,
> I hope I can update the information in the future.

Yes, please update the pages...

> >> You are talked about journaling. This schema works well for a disk, but
> >> what about a piece of ram? What about a crazy kernel that write in that
> >> area for a bug? Do you remember for example the e1000e bug? It's not
> > 
> > I believe you need both journaling *and* write protection. How do you
> > handle power fault while writing data?
> 
> Ah now the write protection is a "needed feature", in your previous
> comment you talked about why not use ext2/3.......

write protection should be handled at block device layer, not
filesystem layer. So yes, use ext2.

You still did not explain how you avoid the need for journalling...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  parent reply	other threads:[~2009-06-24 17:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4a4254e2.09c5660a.109d.46f8@mx.google.com>
2009-06-24 16:49 ` [PATCH 00/14] Pramfs: Persistent and protected ram filesystem 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 [this message]
2009-06-13 13:20 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
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

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=20090624174657.GA6618@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --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=marco.stornelli@gmail.com \
    --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 NNTP newsgroup(s).