RFC: enhancing the root mount logic

[M. Warner Losh]

In message: <AANLkTimUgLAYfM7FJ32hMmF8SEtUYYTrOMKBZep0zDJs at mail.gmail.com>
            Adrian Chadd <adrian at FreeBSD.org> writes:
: On 25 August 2010 00:55, M. Warner Losh <imp at bsdimp.com> wrote:
: >
: > You can get away from a large MD by having a small MD and pivoting to
: > large storage.  Linux does this, as Bakul said, and it scales from the
: > ultra-small 4MB Mips router up to the highest multicore server.
: >
: 
: But as someone's said before - and as I've been a Linux sysadmin here
: and there, I've been bitten more than once by the linux mdroot setup
: where only the -bare minimum- modules needed to bring the system up
: are in the mdroot. Woe be if you have to swap hardware in a hurry -
: double woe if your distribution provides lots of nice "autodetect"
: methods for figuring out which modules should be in the mdroot and
: does this for you automatically. You can manually build modules into
: mdroot but that isn't any good when you're trying to boot a
: post-failed system on alternative hardware.
: 
: The FreeBSD method has been nice - I can compile a lean GENERIC but
: use /boot/loader.conf to load modules at boot time to use alternative
: storage/network mechanisms.
: 
: I'm not saying the whole Linux initrd approach is -bad-; i'm just
: saying it needs to be thought through a little more first.

No body is saying that the only way to do things (or even the default
way) is via the Linux mdroot thing.  We're saying that it is *A* way
to bootstrap a kernel that uses the ramfs to find the proper location
of root to mount (maybe after initializing the device where root is),
pivot to that new location.

Marcel's current proposal seems simpler (and less flexible) than
this.  The proof in the pudding will be his ability to handle the
'layered' cases of encryption or compression I brought up earlier.

Warner