Transferring the root filesystem to a ramdisk?

[Oliver Fromme]

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 <cpghost at cordula.ws> 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