From owner-freebsd-arch@FreeBSD.ORG Wed Aug 25 01:57:33 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F005C106566B; Wed, 25 Aug 2010 01:57:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AEF278FC0A; Wed, 25 Aug 2010 01:57:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7P1pZ9V001461; Tue, 24 Aug 2010 19:51:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 24 Aug 2010 19:51:45 -0600 (MDT) Message-Id: <20100824.195145.29593248078694701.imp@bsdimp.com> To: adrian@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20100824.105546.1002438156525560711.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xcllnt@mac.com, freebsd-arch@FreeBSD.org Subject: Re: RFC: enhancing the root mount logic X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 01:57:34 -0000 In message: Adrian Chadd writes: : On 25 August 2010 00:55, M. Warner Losh 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