Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Aug 2010 19:51:45 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        adrian@FreeBSD.org
Cc:        xcllnt@mac.com, freebsd-arch@FreeBSD.org
Subject:   Re: RFC: enhancing the root mount logic
Message-ID:  <20100824.195145.29593248078694701.imp@bsdimp.com>
In-Reply-To: <AANLkTimUgLAYfM7FJ32hMmF8SEtUYYTrOMKBZep0zDJs@mail.gmail.com>
References:  <C6B677DB-5CC8-46C1-B551-7BEB7BF953E0@mac.com> <20100824.105546.1002438156525560711.imp@bsdimp.com> <AANLkTimUgLAYfM7FJ32hMmF8SEtUYYTrOMKBZep0zDJs@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <AANLkTimUgLAYfM7FJ32hMmF8SEtUYYTrOMKBZep0zDJs@mail.gmail.c=
om>
            Adrian Chadd <adrian@FreeBSD.org> writes:
: On 25 August 2010 00:55, M. Warner Losh <imp@bsdimp.com> wrote:
: >
: > You can get away from a large MD by having a small MD and pivoting =
to
: > large storage. =A0Linux does this, as Bakul said, and it scales fro=
m 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100824.195145.29593248078694701.imp>