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.
next prev 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.