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