From owner-freebsd-multimedia@FreeBSD.ORG Mon Feb 2 09:18:18 2004 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60E1F16A4CE for ; Mon, 2 Feb 2004 09:18:18 -0800 (PST) Received: from lurza.secnetix.de (lurza.secnetix.de [195.143.231.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264DA43D39 for ; Mon, 2 Feb 2004 09:18:16 -0800 (PST) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (jajcho@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.9p2/8.12.9) with ESMTP id i12HI5b0039592; Mon, 2 Feb 2004 18:18:06 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.9p2/8.12.9/Submit) id i12HI42L039591; Mon, 2 Feb 2004 18:18:04 +0100 (CET) (envelope-from olli) Date: Mon, 2 Feb 2004 18:18:04 +0100 (CET) Message-Id: <200402021718.i12HI42L039591@lurza.secnetix.de> From: Oliver Fromme To: freebsd-multimedia@FreeBSD.ORG, cpghost@cordula.ws In-Reply-To: <20040201112747.7785640826@fw.farid-hajji.net> X-Newsgroups: list.freebsd-multimedia User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.9-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Transferring the root filesystem to a ramdisk? X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-multimedia@FreeBSD.ORG, cpghost@cordula.ws List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 17:18:18 -0000 Cordula's Web 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