On Thu, Apr 12, 2012 at 10:56:00PM +0000, Duncan wrote:
> Hugo Mills posted on Thu, 12 Apr 2012 22:55:46 +0100 as excerpted:
> > The general advice is -- use a single-device root filesystem, or an
> > initramfs. These are simple, supported, and will generally get good
> > help. Any other configuration will cause you to be told to use an
> > initramfs. So far, I've not heard any concrete reason why one shouldn't
> > be used except "ooh, I don't understand them, and they're scary!".
> 
> FWIW, device names appear to be reasonably stable, here.  Stable enough 
> that I currently have this built into the kernel as part of my kernel 
> command line:

   That's all well and good for you, but my point is that in the
general case, device names are *not* stable, and the kernel does *not*
claim to guarantee this. If you assume that they are stable, and your
system breaks as a result, then you get to keep both pieces. Your
choice, but your risk as well. The recommendation for a stable
reliable system is to run btrfs dev scan before mounting a btrfs
filesystem.

> md=3,/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 root=/dev/md3p1
> 
> When I need to override that to mount the primary backup/recovery root, 
> this as part of grub2's linux line extends/overrides the kernel builtin:
> 
> md=9,/dev/sda12,/dev/sdb12,/dev/sdc12,/dev/sdd12 root=/dev/md9p1

   So you're doing the same thing as btrfs's "device=" mount option.
Again, if this works, all well and good, but it'll break if devices
move around, requiring the manual step. If you want to avoid that and
have it all Just Work, use an initrd (for both MD and btrfs).

> When I boot from thumbdrive or otherwise might trigger device reordering, 
> grub's interactivity allows me to find the correct mds and substitute 
> device names as appropriate.  And yes, if you're wondering,
> init=/bin/bash is tested and known to work, too. =:^)
> 
> I don't see why btrfs would have additional kernel device naming or 
> finding problems that md doesn't already have.

   As far as I recall, MD also requires userspace help in order to
reassemble a device correctly, except when v0.9 superblocks are used
(which have limitations on the set of other features they support).

> So while I'd agree that multi-device noinitr* btrfs builtin might not be 
> appropriate as a general distro-wide solution, it does seem quite 
> reasonable (here) for sysadmins familiar enough with their own systems to 
> have custom-built no-module-loading kernels in general, to be able to do 
> the same with btrfs.

   I disagree. You could conceivably get the kernel to scan every
single block device it knows about as the device is discovered, but
then the kernel would take unnecessarily long to boot (consider
something with a stack of DVD drives -- you'd have to wait for each
one to spin up before scanning it). If you were to restrict the set of
devices scanned, you're putting policy into the kernel, which would
get rejected pretty much instantly by anyone upstream.

> That's one of a couple reasons I don't use lvm2, as well.  Both lvm2 and 
> an initr* add complexity and thus recovery failure risk due to admin fat-
> fingering or failure to anticipate and test all permutations of failure 
> mode, for little or no gain in my current deployments.

   Again, that's good for you, but all such attempts should be viewed
as unreliable workarounds, not as recommended and supported
approaches.

>  Because lvm2 requires an initr* to handle root, it's TWO such
> layers of additional complexity to test the failure modes for and be
> prepared to deal with at recovery time. The added complexity and
> risk is simply not a reasonable tradeoff, for me, and I sleep better
> with a tested confidence in my disaster recovery abilities. =:^)

   I have had my initrd (for root on LVM on MD) fail precisely once in
8 years or so, and that was down to my upgrading some LVM tools
manually and not rebuilding the initrd. If you stick to your
distribution's packages (at least for boot-critical things), then I
would think it highly unlikely you'll end up with a system that fails
to boot. If you muck around with it manually and it breaks, then I
would suggest you treat it as a learning experience.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Our so-called leaders speak/with words they try to jail ya/ ---   
        They subjugate the meek/but it's the rhetoric of failure.