All of lore.kernel.org
 help / color / mirror / Atom feed
From: Padraig Brady <padraig@antefacto.com>
To: linux-kernel@vger.kernel.org
Subject: Re: ramdisk/tmpfs/ramfs/memfs ?
Date: Fri, 27 Apr 2001 18:53:07 +0100	[thread overview]
Message-ID: <3AE9B203.88B6C799@antefacto.com> (raw)
In-Reply-To: <3AE99CE8.BD325F52@antefacto.com>  <Pine.LNX.3.96.1010426203656.22847A-100000@medusa.sparta.lu.se> <15296.988386995@redhat.com>

David Woodhouse wrote:
> 
> padraig@antefacto.com said:
> > btw I get my initial root filesystem from a compact flash that can be
> > accessed just like a hardisk. It's writeable also like a harddisk, but
> > we boot with it readonly, and only mount it rw if we want to save
> > config or whatever. We definitely wouldn't swap to it as it has
> > limited erase/write cycles. The filesystem is compressed ext2.
> 
> Why copy it into RAM? Why not use cramfs and either turn the writable
> directories into symlinks into a ramfs which you create at boot time, or
> union-mount a ramfs over the top of it?

? I never said I copied it into RAM. The ramfs is just used for /tmp &
/var
which are symlinks on the flash. I didn't know you could read/write
cramfs
like ext2/JFFS2? I still want to be able to update/create/delete files
like a normal ext2 partition. Oh I see the confusion, sorry my fault,
when
I said the root filesystem is compressed ext2, I meant it's ext2 with
chattr +c done on all files (the e2compr patch implmenents it). By the
way why isn't e2compr a standard part of the kernel. I've have no
problems
at all with it.

I didn't know about union-mounting, seems useful.

As for whether to use tmpfs/ramfs I think they do basically the same
thing 
only the implementation is different. tmpfs uses shared mem and so is 
probably more portable than ramfs which it tightly coupled with VFS. I
think I'll use ramfs (with limits patch) so.

> padraig@antefacto.com said:
> > As for using JFFS2 + MTD ramdisk intead of ext2+e2compr+ramdisk is not
> > an option as the only advantage would be journalling, you still can't
> > resize. IMHO JFFS is only required where you have flash without an IDE
> > interface.
> 
> True. We are currently lacking a compact, compressing, journalling
> filesystem for use on block devices. It's been suggested that we could make
> JFFS2 work on them, by making a fake MTD device which uses a block device
> as backing store. Nobody's yet shown me the code though :)

How much more efficent is JFFS than say ext3+e3compr, wrt:
logic size/logic speed/RAM requirements/filesystem structure size.

> --
> dwmw2

Padraig.

  parent reply	other threads:[~2001-04-27 16:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-26 19:40 ramdisk/tmpfs/ramfs/memfs ? Padraig Brady
2001-04-26 18:48 ` Bjorn Wesen
2001-04-26 20:39   ` Marko Kreen
2001-04-27  0:37     ` H. Peter Anvin
2001-04-27 11:32       ` mirabilos
2001-04-27 13:41         ` Christoph Rohland
2001-04-26 20:49   ` H. Peter Anvin
2001-04-26 22:25     ` Ingo Oeser
2001-04-27  9:36   ` David Woodhouse
2001-04-27 11:36     ` mirabilos
2001-06-22  8:15     ` Padraig Brady
2001-04-27 15:56   ` David Woodhouse
2001-04-27 16:19     ` mirabilos
2001-04-27 17:39     ` David L. Parsley
2001-04-27 17:53     ` Padraig Brady [this message]
2001-04-27 17:23       ` Xavier Bestel
2001-04-28 10:30     ` David Woodhouse
2001-04-27 16:23   ` Padraig Brady
2001-04-27 14:31     ` Bjorn Wesen
2001-04-27 15:38     ` Christoph Rohland
2001-04-27  7:58 ` Christoph Rohland

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=3AE9B203.88B6C799@antefacto.com \
    --to=padraig@antefacto.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.