From: "H. Peter Anvin" <hpa@transmeta.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: / on ramfs, possible?
Date: Mon, 30 Oct 2000 15:37:01 -0800 [thread overview]
Message-ID: <39FE061D.A68170B1@transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0010302329140.16675-100000@imladris.demon.co.uk>
David Woodhouse wrote:
>
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > Pardon?! This doesn't make any sense...
> >
> > The question was: how do switch from the initrd to using the ramfs as /?
> > Using pivot_root should do it (after the pivot, you can of course nuke
> > the initrd ramdisk.)
>
> My question is: What do you want to do that for? You can nuke the initrd
> ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
> why not just keep your root filesystem in the initrd where it started off?
>
Umm... because the size of a ramdisk is fixed, but the size of a ramfs is
flexible?
I can certainly understand this problem... I might in fact do exactly
this in the next version of my SuperRescue disk. There, the ramdisk
which is the real root is populated from a .tar.gz file; the initrd is
just there to unpack the .tar.gz file onto the "real" ramdisk; the initrd
is then jettisoned.
Why not just have the real root be the initrd, you ask? It's too large:
since an initrd needs to exist in both compressed form and uncompressed
form in memory at the same time; it would mean SuperRescue would no
longer work on systems with 64 MB RAM. If I went to ramfs it might
actually work on systems with 48 MB RAM, albeit you better not need to
much space in / (or conversely, it would suddenly let you put a whole lot
more stuff in /tmp if you have 512 MB.)
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-10-30 23:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-30 7:27 / on ramfs, possible? Anders Eriksson
2000-10-30 7:34 ` H. Peter Anvin
2000-10-30 23:24 ` David Woodhouse
2000-10-30 23:26 ` H. Peter Anvin
2000-10-30 23:32 ` David Woodhouse
2000-10-30 23:37 ` H. Peter Anvin [this message]
2000-10-30 23:39 ` Jeff Garzik
2000-11-01 9:16 ` aer-list
2000-10-30 12:42 ` Alan Cox
2000-10-30 20:09 ` Stuart Lynne
2000-10-30 8:39 Adam J. Richter
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=39FE061D.A68170B1@transmeta.com \
--to=hpa@transmeta.com \
--cc=dwmw2@infradead.org \
--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 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).