Date: Tue, 3 Feb 2004 14:32:56 +0100 (CET) From: Cordula's Web <cpghost@cordula.ws> To: freebsd-multimedia@FreeBSD.ORG, cpghost@cordula.ws Subject: Re: Transferring the root filesystem to a ramdisk? Message-ID: <20040203133256.AB92040826@fw.farid-hajji.net> In-Reply-To: <200402021718.i12HI42L039591@lurza.secnetix.de> (message from Oliver Fromme on Mon, 2 Feb 2004 18:18:04 %2B0100 (CET)) References: <200402021718.i12HI42L039591@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. 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? What happens to the filesystem that (was) mounted on /? > 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. 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 :( > 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. 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? 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? > > * 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. Yes, that's exactly the problem. It means a nearly full reboot, but not 100%, because that would kill e.g. the ramdisk. Hairy it is... > Regards > Oliver > > 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? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040203133256.AB92040826>