From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R4wRd-0001M3-K3 for garchives@archives.gentoo.org; Sat, 17 Sep 2011 15:04:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 41E7321C0E5 for ; Sat, 17 Sep 2011 15:04:41 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id BDDB821C038 for ; Sat, 17 Sep 2011 14:10:32 +0000 (UTC) Received: by bkbzt12 with SMTP id zt12so5708465bkb.40 for ; Sat, 17 Sep 2011 07:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=p7x2e3YlDQ93TSkiEnEz1Qo1W6dJXakNzRPZiGWPovI=; b=Ia3SzgzV+/lbj+6ltvRYS/lvRNTDVjguRvFFU034BLlrmH3KnpG+h/Ptbssm5f8J/A zEFmbe0gZENXm3qBgHDAVDehKNuEgMAoRi21YpoFWo+9rDp9nurY8JXF2L3FrEsY0yRU l3laAapOAs9HZkEkzrID0w5b5cqw+ryk+CKB8= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.130.11 with SMTP id q11mr355856bks.91.1316268631843; Sat, 17 Sep 2011 07:10:31 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.143.67 with HTTP; Sat, 17 Sep 2011 07:10:31 -0700 (PDT) In-Reply-To: <1330478.gIiuRHWAbS@eve> References: <1740055.XA9oyAS8HQ@eve> <1884169.5d71snpPpZ@eve> <1330478.gIiuRHWAbS@eve> Date: Sat, 17 Sep 2011 10:10:31 -0400 X-Google-Sender-Auth: EA4lbkDK6E-vebAUn3bhcaFY66M Message-ID: Subject: Re: [gentoo-dev] Re: udev and /usr From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=001517447aee3ae23104ad23acd0 X-Archives-Salt: X-Archives-Hash: 04eeedea5c096653c5cfb7e03c8fa398 --001517447aee3ae23104ad23acd0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 17, 2011 at 2:16 AM, Joost Roeleveld wrote: > > Except that Redhat and Centos use LVM by default. Which will also mean that > "simple users" also end up using LVM. > Then again, they also end up with an initr* and a generic kernel for > everything under the sun. > I haven't properly looked at the kernel-configs from redhat lately, but I > don't think they include all the possible hardware options be default? > > > The typical mainstream binary distro approach is to: 1. Build every module under the sun that won't cause more support headaches than benefits. 2. Build a really smart initramfs that can find root whether it is on raid, lvm, luks, or on a SAN behind luks and a VPN (ok, I'm stretching it a little). 3. Deploy that on everything. With an initramfs you can essentially build a completely modular kernel, since the kernel can rely on any module it wishes right from the start. However, once the initramfs is done the kernel is still a minimal size since unused modules don't occupy space (the initramfs wipes itself out of ram as its last step, unless in a debug mode). Sure, the fancy initramfs takes work, but since the install image is one-size-fits-all it is less maintenance in the long haul. Plus you can replace your motherboard and still boot the same drive image. The downside is that it might take an extra second or two to boot, but dracut is pretty fast. Honestly, if I were running a server setup I'd probably consider using an intiramfs. They're a lot less susceptible to being messed up if for whatever reason the drives get re-ordered in the BIOS (root=UUID, or with LVM the device names can usually be trusted). I once booted off of a rescue CD that for whatever reason changed the major numbers assigned to my raid devices and for a while I could never predict what /dev/md# my root would end up with. That is what started my quest to get dracut working, which I'll continue whenever git.kernel.org is back up... Rich --001517447aee3ae23104ad23acd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Sep 17, 2011 at 2:16 AM, Joost Roeleveld <joost@antarean.org> wrote:<= br>

Except that Redhat and Centos use LVM by default. Which will also mean that=
"simple users" also end up using LVM.
Then again, they also end up with an initr* and a generic kernel for
everything under the sun.
I haven't properly looked at the kernel-configs from redhat lately, but= I
don't think they include all the possible hardware options be default?<= br>


The= typical mainstream binary distro approach is to:

= 1. =A0Build every module under the sun that won't cause more support he= adaches than benefits.
2. =A0Build a really smart initramfs that can find root whether it is = on raid, lvm, luks, or on a SAN behind luks and a VPN (ok, I'm stretchi= ng it a little).
3. =A0Deploy that on everything.

<= /div>
With an initramfs you can essentially build a completely modular kerne= l, since the kernel can rely on any module it wishes right from the start. = =A0However, once the initramfs is done the kernel is still a minimal size s= ince unused modules don't occupy space (the initramfs wipes itself out = of ram as its last step, unless in a debug mode). =A0

Sure, the fancy initramfs takes work, but since the ins= tall image is one-size-fits-all it is less maintenance in the long haul. = =A0Plus you can replace your motherboard and still boot the same drive imag= e. =A0The downside is that it might take an extra second or two to boot, bu= t dracut is pretty fast.

Honestly, if I were running a server setup I'd prob= ably consider using an intiramfs. =A0They're a lot less susceptible to = being messed up if for whatever reason the drives get re-ordered in the BIO= S (root=3DUUID, or with LVM the device names can usually be trusted). =A0I = once booted off of a rescue CD that for whatever reason changed the major n= umbers assigned to my raid devices and for a while I could never predict wh= at /dev/md# my root would end up with. =A0That is what started my quest to = get dracut working, which I'll continue whenever git.kernel.org is back up...

Rich
--001517447aee3ae23104ad23acd0--