Date: Mon, 2 Feb 2004 18:18:04 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-multimedia@FreeBSD.ORG, cpghost@cordula.ws Subject: Re: Transferring the root filesystem to a ramdisk? Message-ID: <200402021718.i12HI42L039591@lurza.secnetix.de> In-Reply-To: <20040201112747.7785640826@fw.farid-hajji.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Cordula's Web <cpghost@cordula.ws> wrote:
>
> > you could mount the replacement root device on '/'
> >
> > alternatively you could make init do the chroot (you have source no? :-)
>
> chroot()ing init looks like a good idea, but:
> 1. Isn't /sbin/init itself mmap()ed to the physical device
> which I'd like to turn off later?
> 2. Other processes, forked earlier from init will also
> be mmap()ed to the physical device, so they'll have to die?
>
> 1. means that chroot() can only happen before /sbin/init is
> created, somewhere around /usr/src/sys/kern/init_main.c:mi_startup()
>
> 2. means that all these processes will die, when the device
> is turned off.
No, they won't die, they'll just block for a brief moment
while the drive is coming back online. Note that "ataidle"
does not turn the device off, but it merely causes the disks
to spin down after a certain idle time. As soon as some
process tries to access the disk, they'll spin up again.
You should not physically remove the drive, though (if it's
in a removable drive bay), nor switch off power from the
drive.
So the chroot solution is probably the easiest solution.
The init process is idle most of the time, so chances are
that it doesn't want to spin up your disk. Init only wakes
up when you send it a HUP signal (i.e. after modifying the
/etc/ttys file), or when one of the daemons from that file
dies (i.e. a getty process). And upon shutdown, of course.
> * A new syscall foo(device_t) is needed.
> * foo() manipulates the vnode for "/", effectively mounting the
> memory device.
I think that would be prohibitively complicated. Keep in
mind that all existing open files on that disk depend on
the vnode, so you would have to manipulate a _lot_ of
data. All memory mappings, locks etc. would have to be
renewed somehow. It's a huge can of worms.
Regards
Oliver
PS: Uhm, why is this in the -multimedia list anyway? :-)
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Perl will consistently give you what you want,
unless what you want is consistency."
-- Larry Wall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402021718.i12HI42L039591>