On Fri, Apr 13, 2012 at 12:48 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote: > 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. The fact is that you _don't_ know that your device names aren't going to change one day, any more than a generation of developers who only worked with ext3 knew that "fsync is expensive and all you really need is the atomic guarantee of mv". [snip] > 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? On debian derivatives at least, creating a distro packaged kernel from a git checkout is a single, fairly short, command. And the logic to create the initramfs is separate from that, triggered when a kernel is installed (and which works even if you just installed a kernel by copying the bzimage to /boot). I'd be surprised if it was much different on any other distro. Everyone needs to start somewhere, but it's not unreasonable to expect an admin to understand how their distro does things, and where to find answers when they don't know, and to verify that their knowledge is correct. The middle of a disaster recovery should not be the first time you've tried a recovery. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
