RFC: enhancing the root mount logic
M. Warner Losh
imp at bsdimp.com
Tue Aug 24 17:01:36 UTC 2010
In message: <C6B677DB-5CC8-46C1-B551-7BEB7BF953E0 at mac.com>
Marcel Moolenaar <xcllnt at mac.com> writes:
:
: On Aug 24, 2010, at 8:52 AM, Bakul Shah wrote:
: >>
: >> I see your point and buy into the argument, but not
: >> entirely. I explicitly mentioned "embedding" and so
: >> far your arguments include things like GENERIC being
: >> 10MB or Linux server startup.
: >>
: >> We're not exactly discussing the same thing are we?
: >
: > This friend's company used linux in an embedded system [it
: > was a fileserver product. Presumably the OS had to run in a
: > restricted environment since the FS space would be for their
: > customers' use + you don't want to have to reload the OS when
: > a disk dies! And yet you want the ability to upgrade your OS
: > s/w etc.]
: >
: > In my job[-2] we used FreeBSD as an embedded OS. IIRC we just
: > ran from a readonly flash FS as root. An upgrade was just a
: > new FS image, including kernel + utilities. Didn't Juniper
: > do something similar?
:
: Juniper's approach is still heavily rooted in PC-class H/W.
: With Book-E, ARM and MIPS products for the low(er)-end and
: in particular without these products having a real harddisk,
: the existing way has shown it's problems and limitations.
:
: Also: Juniper has hacked a few tools, including the kernel
: at large and md(4) in particular to implement features they
: needed/wanted, which I'd like to get away from.
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.
Warner
More information about the freebsd-arch
mailing list