On 11/23/2014 10:53 AM, Gour wrote:
On Sun, 23 Nov 2014 10:23:35 -0500 Anton Aylward
wrote: That's an interesting strawman argument but I don't see it as being realistic or common.
I suggest you to visit #btrfs (Freenode) and/or some btrfs mailing lists to expand your vision a bit. ;)
You mistake my meaning and intent. Which was that this has anything to do with the necessity of a) boot failures being specific to BtrFS systems b) the options available for "boot debugging" that are applicable to other file systems are somehow inapplicable to BtrFS There's still been noting state that necessitates having the root of a BtrFS being a subvolume of itself. Those arguments too are all strawmen, Please do not construe this to mean that there are not ways to render a system unbootable, for various meanings of 'unbootable', nor that those ways can be carried out on a system with a BrtrFS root file system. BTDT. Nor does it mean that earlier versions of the BtrFS were unstable enough to cause the systems to become unbootable for reasons that were specific to the root BtrFS. Neither does that mean that even mature file systems do not have fringe conditions, some discovered, some yet to be discovered, that can make them unstable. The reality is that BtrFS is the youngest of the 'popular' file systems because of its association with SSD and has been, like systemd, like KDE4, pushed out aggressively even while immature, and has garnered q lot of criticism when like Kde4 and systemd, its early instances met with problems and failures. Such is the nature of the FSS development model. I've been using BtrFS without BtrFs specific boot problems since late opensuse 12.1. Yes, I've had kernel updates that have gone wrong, but the 'have gone wrong' was confined to /boot which is a ext2FS. The technique I described of using the recovery disk to mount a BtrFS rootFS on the RAMFS /mnt, then mount the hard disk partition /boot on /mnt/boot, then do the /sys, /dev, /proc trickery and chroot to /mnt and then mkinitrd all works. It worked before I started using BtrFS and it works now on a BtrFS without a subvolume of itself. Hypothesising a elaborate configuration specifically to 'show' that a subvolume-of-itself is needed is an unrealistic strawman. I'm not sure how I would classify failing to recognise that snapshots are based around COW rather than real copies. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org