Hugo Mills posted on Fri, 13 Apr 2012 14:16:32 +0100 as excerpted: > 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.
BTW, I don't believe I've thanked you for the replies, yet. Thanks, and I don't disagree with the rest. I guess I generally agree here, too... with /generally/ stressed. But the wiki should cover more than the default, "general" case. Meanwhile [kernel command line] ... >> md=3,/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 root=/dev/md3p1 > So you're doing the same thing as btrfs's "device=" mount option. Same general thing, yes. > 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). Obviously, for systems where it all moves around at every boot, this isn't going to be a very useful alternative, I'll agree. But that's not the case on a lot of hardware. And the trouble with "just works" isn't when it does INDEED "just work", but when it doesn't. In that case, the admin needs to be comfortable enough with the system and his understanding of it to get things back into operational condition. The more layers of unnecessary complexity (like a shouldn't be necessary initr*) there are, the more difficult that "grok the system well enough to be reasonably confident in one's ability to restore it" status is to achieve, and the higher the risk of failure, should the admin's disaster recovery skills actually be needed. > 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). I've read that is true, altho I've not tested it, I've simply gone with 0.90 superblocks, because here, the cost of 0.90 is rather low compared to the benefits of no-userspace-required assembly from kernel commandline and detected data. If btrfs (or md) should lose that ability, it'd be a shame. >> 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. No need to have the kernel scan everything (certainly not by default) OR limit policy... while still retaining flexibility. Simply keep the ability to have it specified on the kernel commandline, for systems with a stable enough device layout that it works. Actually, with a flexible enough bootloader, and grub2 certainly seems at least close to that already, as with its modules it already supports both mdraid and lvm2 as well as btrfs (and apparently zfs as well), any scanning ability as well as site configuration and policy, could be and already is to some degree, built into the bootloader's modules, as long as the kernel commandline (or other similar mechanism) remains available to handle the necessary data passed to it from the bootloader. > 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. Stick to a distro's packages? How are people only running distro packages supposed to run the patches they're asked to test on the list, talk the distro package maintainer into including possibly one-shot debugging patches into a new general rollout? True, some distros are packaging and even supporting btrfs already, and some users, their own admins, are reckless enough to dive right in, without checking project status, or the wiki, or the list... but that can hardly be the /target/ audience for btrfs at this point, right? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
