All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [patch] rewrite rd
Date: Tue, 4 Dec 2007 01:55:17 -0600	[thread overview]
Message-ID: <200712040155.21124.rob@landley.net> (raw)
In-Reply-To: <20071204042628.GA26636@wotan.suse.de>

On Monday 03 December 2007 22:26:28 Nick Piggin wrote:
> There is one slight downside -- direct block device access and filesystem
> metadata access goes through an extra copy and gets stored in RAM twice.
> However, this downside is only slight, because the real buffercache of the
> device is now reclaimable (because we're not playing crazy games with it),
> so under memory intensive situations, footprint should effectively be the
> same -- maybe even a slight advantage to the new driver because it can also
> reclaim buffer heads.

For the embedded world, initramfs has pretty much rendered initrd obsolete, 
and that was the biggest user of the ramdisk code I know of.  Beyond that, 
loopback mounts give you more flexible transient block devices than ramdisks 
do.  (In fact, ramdisks are such an amazing pain to use/size/free that if I 
really needed something like that I'd just make a loopback mount in a ramfs 
instance.)

Embedded users who still want a block interface for memory are generally 
trying to use a cramfs or squashfs image out of ROM or flash, although there 
are flash-specific filesystems for this and I dunno if they're actually 
mounting /dev/mem at an offset or something (md?  losetup -o?  Beats me, I 
haven't tried that myself yet...)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

  parent reply	other threads:[~2007-12-04  7:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-04  4:26 [patch] rewrite rd Nick Piggin
2007-12-04  4:26 ` Nick Piggin
2007-12-04  6:29 ` Andrew Morton
2007-12-04  7:01   ` Nick Piggin
2007-12-04  7:08     ` Nick Piggin
2007-12-04  7:55 ` Rob Landley [this message]
2007-12-04  9:29   ` Nick Piggin
2007-12-04 19:53     ` Rob Landley
2007-12-04  9:54 ` Christian Borntraeger
2007-12-04 10:10   ` Nick Piggin
2007-12-04 11:21     ` [patch] rd: support XIP Nick Piggin
2007-12-04 11:23       ` [patch] ext2: xip check fix Nick Piggin
2007-12-05 15:43         ` Carsten Otte
2007-12-05 23:33           ` Nick Piggin
2007-12-06  8:43             ` Carsten Otte
2007-12-06  8:52               ` Nick Piggin
2007-12-06  9:59                 ` Carsten Otte
2007-12-06 10:18                   ` Nick Piggin
2007-12-06 10:24                     ` Carsten Otte
2007-12-06 18:11                       ` Rob Landley
2007-12-07  3:22                         ` Jared Hulbert
2007-12-07  4:17                           ` Rob Landley
2007-12-07  4:23                             ` Nick Piggin
2007-12-07  4:40                             ` Jared Hulbert
2007-12-07  8:59                           ` Carsten Otte
2007-12-07  9:52                             ` Jared Hulbert
2007-12-04 11:26       ` [patch] rd: support XIP Andrew Morton
2007-12-04 11:35         ` Nick Piggin
2007-12-04 13:00           ` [patch] mm: fix XIP file writes Nick Piggin
2007-12-10 14:38             ` Christian Borntraeger
2007-12-12  4:03               ` Nick Piggin
2007-12-04 12:06       ` [patch] rd: support XIP Duane Griffin
2007-12-04 13:03         ` [patch] rd: support XIP (updated) Nick Piggin
2008-01-14 16:47 ` [patch] rewrite rd Matthew Wilcox
2008-01-14 17:21   ` Jens Axboe

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=200712040155.21124.rob@landley.net \
    --to=rob@landley.net \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=borntraeger@de.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /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.