Date: Mon, 23 Aug 2010 17:12:01 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: freebsd-arch@FreeBSD.org Subject: Re: RFC: enhancing the root mount logic Message-ID: <20100823.171201.107001114053031707.imp@bsdimp.com> In-Reply-To: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net> References: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net>
Marcel Moolenaar <marcelm@juniper.net> writes:
: All,
:
: In embedded products, software is possibly installed as an image onto
: an actual storage device. This means that mounting the storage device
: as root is not enough to have a usable root file system. The rough
: draft below is an idea to enhance the root mount from having ad-hoc
: quirks to a well-defined and recursive mechanism to allow a wide-
: range of use cases.
:
: The root mount logic is recursive as follows:
: 1. The kernel mounts devfs as root (is it is now).
: 2. The kernel will re-mount root by virtue of reading a file, called
: /.mount.conf, in the current root file system and following the
: directives is it. devfs synthesizes the contents of this file.
:
: At each iteration, the kernel will:
: 1. move the devfs mount from /dev in the old file system to /dev in
: the new file system.
: 2. As per the directives or unconditionally, the kernel will re-mount
: the old root file system under /.mount (or some other name) within
: the new file system.
:
: devfs will synthesize the contents of /.mount.conf as per the kernel
: configuration and tunables. The administrator (or install process)
: will create and populate /.mount.conf for all other cases.
:
: Directives in /.mount.conf are envisioned to be something like:
:
: {FS}:{MOUNTPOINT} e.g. ufs:/dev/da0
: a root mount alternative. The order of the alternatives in
: the file determines the priority.
:
: .ask
: a root mount alternative that asks the operator to specify
: what the root mount should be.
:
: .wait N .e.g. .wait 5
: wait at most N seconds for a root mount alternative to
: succeed. If an alternative does not succeed within that
: time, move on to the next alternative.
:
: .onfail {panic|reboot|retry|continue}
: Tells the kernel what to do in case it can't successfully
: complete the root mount as directed to.
:
: The .wait directive works better (probably) if we have events that
: signify the arrival of a file system or device special file, so that
: we can wait for at most N seconds after the last event. This also
: allows us to wait for a separate interval between events.
:
: As an example, consider:
:
: [devfs] /.mount.conf:
: ufs:/dev/da0
: .ask
: .wait 5
: .onfail panic
:
: [ufs:/dev/da0] /.mount.conf
: md0:/images/OS-image-1.0.iso
: unionfs:/jail/freebsd-8-stable
: .wait 0
: .onfail continue
:
: In the example, the kernel will mount devfs, read /.mount.conf and
: wait at most 5 seconds to mount the UFS on /dev/da0. If that fails,
: the kernel will ask (once) and panic in case of failure.
:
: If the UFS root mount succeeded, the kernel will re-mount devfs
: underneath /dev. Since this is the first non-devfs root file system,
: the kernel will not re-mount the old root under /.mount.
:
: Since there's a /.mount.conf on the UFS, the kernel will read it
: and repeat the process. First it'll try and mount the OS image
: in /images/OS-image-1.0.iso and if it's not present will try to
: mount some -stable 8 chroot using unionfs (not necessarily a
: real-world example here :-) If either fails, the kernel will
: continue booting using the current root file system. Assuming that
: the image is present, the kernel will re-mount root, move devfs
: underneath /dev in the MD root and remount ufs:/dev/da0 under
: /.mount in the MD root. This gives the following picture:
:
: / md0:[ufs:/dev/da0]/images/OS-image-1.0.iso
: /.mount ufs:/dev/da0
: /dev devfs
:
:
: Things to not explicitly touched upon:
: o root mount options
: o directives to instruct the kernel what to run as the initial
: process to eliminate the rather ad-hoc hardcoding. E.g:
: .init /sbin/init
: .init /sbin/init.old
:
: Is this something that people feel is worth fleshing out and
: prototyping?
This sounds very interesting. If kept simple, I could see how this
would make my life a lot easier.
However, all this scripting sounds a bit like a very simple shell in
the kernel. What advantages are there to this approach vs having the
ability to run a simple shell script or executable and "pivot" the root
to a new location? And how do you emulate the mount_foo programs for
foo filesystems? Some of them do weird things that might not
translate well into the kernel...
As you can see, I'm torn about how I feel about the idea. For simple
cases, I think it is great, but as complexity builds, I become less
sure. What if that iso image was compressed? What if I had a
software RAID of disks or flash devices? What about crypto? I know I
can handle those cases in /bin/sh, but will each new one require more
code in the kernel? What would df and/or mount tell you about the
now-hidden file systems?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100823.171201.107001114053031707.imp>