From owner-freebsd-multimedia@FreeBSD.ORG Wed Feb 4 02:35:16 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 0B6D016A4CE for ; Wed, 4 Feb 2004 02:35:16 -0800 (PST) Received: from lurza.secnetix.de (lurza.secnetix.de [195.143.231.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A560643D39 for ; Wed, 4 Feb 2004 02:35:12 -0800 (PST) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lwxklm@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.9p2/8.12.9) with ESMTP id i14AZ1b0021222; Wed, 4 Feb 2004 11:35:02 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.9p2/8.12.9/Submit) id i14AZ07w021221; Wed, 4 Feb 2004 11:35:00 +0100 (CET) (envelope-from olli) Date: Wed, 4 Feb 2004 11:35:00 +0100 (CET) Message-Id: <200402041035.i14AZ07w021221@lurza.secnetix.de> From: Oliver Fromme To: freebsd-multimedia@FreeBSD.ORG, cpghost@cordula.ws In-Reply-To: <20040203133256.AB92040826@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: Wed, 04 Feb 2004 10:35:16 -0000 BTW, please include an attribution line when quoting others. That makes it a lot easier to see who wrote which parts of the thread. Cordula's Web wrote: > > > 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. > > Hmmm, let's see: > * / is mounted on, say, /dev/da0s1a > * some processes (including /sbin/init) have open files from / > * /sbin/init chroot()s to something else. > * new processes spawned by init inherit the chroot() settings. > * /dev/da0 is powered down > * ??? > > What happens now to /sbin/init? Nothing. As long as the existing init process is idle, (i.e. it doesn't need to be scheduled for time slices), nothing happens. To be more exact: As long as the init process doesn't need any executable pages which aren't already in memory. > What happens to the filesystem that (was) mounted on /? othing. It is still mounted, but inaccessible by any processes after the chroot() call. > > You should not physically remove the drive, though (if it's > > in a removable drive bay), nor switch off power from the > > drive. > > Yep, that's the catch. The drive should be powered off, and > it should be potentially removable/replacable. Then you can't use the chroot() solution. > It's remarkable > that it is so difficult to change the root device on-the-fly. > I didn't expect it to be so difficult :( Well, just _changing_ the root device (as it appears to processes) is easy -- that's what chroot() does. But what you really want is to completely _unmount_ the original root device. That's not possible in UNIX. > > 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. > > Any process that gets orphaned will be inherited by init. > This means that the PPID of that process will change to 1. > But will init not be notified of this, therefore reactivated? Right. I didn't think of that. The init process will be notified and pick up the exit code of the orphaned process. But that part of init should already be mapped into memory, so no physical disk access should be necessary. > Yes, init is idle most of the time, but is it safe to assume > that it will not access its own drive or backing store? No, that's not safe to assume. If the drive has just spun down, then it doesn't matter much, because it'll spin up automatically for a short time, then spin back down when the idle time has elapsed again. But if you remove power from the drive (or remove the whole drive), then you're asking for trouble, sooner or later. > > PS: Uhm, why is this in the -multimedia list anyway? :-) > > No idea. This started on questions@, but migrated somehow. Sorry > if it is off topic here. What would the appropriate place be? Depends on your kind of application. :-) If you need it for some kind of embedded system, then the -small mailing list might be appropriate. BTW, why are you booting from a hard disk in the first place? There are several alternatives that might be possible, depending on your requirements. For example, you could boot from CD-R. Or, if you have a network connection and a server nearby, you could boot from the network, without any drives in the box. Finally, a very common approach is to use a CF-to-ATA adaptor and boot from a Compact-Flash card. That's how I boot my self-made mp3 player box, which -- of course -- runs FreeBSD. :) Regards Oliver -- 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. "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97