>On Nov 7, 2013, at 4:45 PM, Michael Göhler <visit@myjm.de> wrote: >> The boot subvolume is then set with ''btrfs subvolume set-default'' andmounted without subvol/subvolid option by Arch''s default mount handler.> >I''m unconvinced it''s a good idea for it to be used behind the scenes > for the described purpose. Consider the following: > >1. btrfs subvolume set-default uses a user space tool and in > my view it''s primarily a user domain behavior modifier for the mountcommand.> >2. It makes the actual mounted subvolume obscured, cat /proc/self/mountinfo > doesn''t show what subvolume is mounted unless subvol= is explicitly used in/etc/fstab.> >3. Grub2 (and I''m pretty sure grubby) do not use the set-default. The GRUB > intent for the prefix to search an absolute path, not one relative to the > default subvolume. There''s a bug that should very recently (week) be fixed, > where GRUB fails to find prefix if set-default is changed. This maybe isn''t > affecting the particular layout you describe where only rootfs is on btrfs, > rather than /boot being on its own subvolume. >Instead of using set-default, I am used to rename the subvolume. I.E. I assume that the root filesystem is a subvolume always called "__active". When I want to rollback, I rename "__active" in "__broken" (or remove it), then I rename (or re-snapshot) "snapshot-yyyymmdd" in "__active".>> That way, we ensure the best compatibility and lowest maintenance, > as we don''t overwrite default init functions. > >I''m sympathetic to the alternative problem, which is that you need to > alter grub.cfg to use the proper rootflags=subvol= to explicitly use the > proper snapshot, and also it would mean altering the /etc/fstab within > that snapshot.With rename you can address both the issues>> >> Now, if we snapshots the root subvolume, the child subvolumes are >> not snapshoted with it. There is no back reference which would >> allow Btrfs to auto-mount the original child subvolumes when we >> mount the snapshot as new root filesystem. Of cause we could >> snapshot the childs separately into their desired directories. But >> this would not help, because our hook snapshots the snapshot again, >> to keep it''s original untouched while rolling back. >> And we don''t have fstab to find out the correct mount points at this earlyboot stage.> >The fact of the matter is, we don''t have the necessary metadata support in > btrfs to understand the relationships between snapshots/subvolumes. > There is a need for this, not least of which is the use case you''re > describing. This has come up with Fedora also for their offline > updates rollback they want to eventually do. And it''s also an issue > with distribution installers which see these snapshots as wholly > unique instances of existing installations, rather than as relatedsnapshots.> > >> >> Atm. all scenarios results in /usr/bin/init not found. >> >> So here comes my question: >> Wouldn''t it be helpful to add a --recursive option to ''btrfs subvolume >> snapshot'' to snapshot child subvolumes together with their parent? >> Or maybe it is possible to add some functionality to reference the >> child subvolumes on the snapshots fs-tree to allow auto-mounting? > > Well and it raises the problem of nested subvolumes making the parent > subvolume undeletable. So I''d question the significant benefit of > making nested subvolume in particular /var. It''s complicating > how the OS is to be put back together again.IIRC the problem of removing a subvolume with a child subvolume, already exists. IMHO the "btrfs sub snapshot" --recursive option could have some valid uses cases. Of course we should add the "btrfs sub delete" --recursive option also. BTW I agree with Chris that partition the filesystem in too much subvolume is a mess from a managemente POV. May be adding an option to "ls" to highlight the subvolumes could alleviate the problem ? G.Baroncelli> > >Chris Murphy-- >To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Nov 8, 2013, at 5:55 AM, Goffredo Baroncelli <kreijack@libero.it> <kreijack@libero.it> wrote:> > Instead of using set-default, I am used to rename the subvolume. > I.E. I assume that the root filesystem is a subvolume always called > "__active". > When I want to rollback, I rename "__active" in "__broken" (or > remove it), then I rename (or re-snapshot) "snapshot-yyyymmdd" > in "__active". > >>> That way, we ensure the best compatibility and lowest maintenance, >> as we don''t overwrite default init functions. >> >> I''m sympathetic to the alternative problem, which is that you need to >> alter grub.cfg to use the proper rootflags=subvol= to explicitly use the >> proper snapshot, and also it would mean altering the /etc/fstab within >> that snapshot. > > With rename you can address both the issuesNow I don''t know what snapshot that is, since it''s just renamed to some non-descriptive name like "root" which happens to, by convention, always be the active root. This is the problem with using user domain to store contextual metadata. We need another way to do this, rather than inject these changes into filename/foldername which are primarily user domain. And we need agreement on a right way to do this rather than distribution convention. We need some distribution collaboration in this area, or this is going to turn into an end-user pain point, with multiboot users top on the list of the injured. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2013-11-08 18:44, Chris Murphy wrote:> > On Nov 8, 2013, at 5:55 AM, Goffredo Baroncelli <kreijack@libero.it> > <kreijack@libero.it> wrote: >> >> Instead of using set-default, I am used to rename the subvolume. >> I.E. I assume that the root filesystem is a subvolume always called >> "__active". When I want to rollback, I rename "__active" in >> "__broken" (or remove it), then I rename (or re-snapshot) >> "snapshot-yyyymmdd" in "__active". >> >>>> That way, we ensure the best compatibility and lowest >>>> maintenance, >>> as we don''t overwrite default init functions. >>> >>> I''m sympathetic to the alternative problem, which is that you >>> need to alter grub.cfg to use the proper rootflags=subvol= to >>> explicitly use the proper snapshot, and also it would mean >>> altering the /etc/fstab within that snapshot. >> >> With rename you can address both the issues > > Now I don''t know what snapshot that is, since it''s just renamed to > some non-descriptive name like "root" which happens to, by > convention, always be the active root. This is the problem with using > user domain to store contextual metadata. We need another way to do > this, rather than inject these changes into filename/foldername which > are primarily user domain. And we need agreement on a right way to do > this rather than distribution convention.Put all the required information in an xattr...> > We need some distribution collaboration in this area, or this is > going to turn into an end-user pain point, with multiboot users top > on the list of the injured.I fully agree: whatever solution we found, it has to be shared across all distributions.> > > Chris Murphy-- To unsubscribe from this list: send the line > "unsubscribe linux-btrfs" in the body of a message to > majordomo@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html >-- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Nov 8, 2013, at 10:59 AM, Goffredo Baroncelli <kreijack@inwind.it> wrote:>> >> Now I don''t know what snapshot that is, since it''s just renamed to >> some non-descriptive name like "root" which happens to, by >> convention, always be the active root. This is the problem with using >> user domain to store contextual metadata. We need another way to do >> this, rather than inject these changes into filename/foldername which >> are primarily user domain. And we need agreement on a right way to do >> this rather than distribution convention. > > Put all the required information in an xattr... > >> >> We need some distribution collaboration in this area, or this is >> going to turn into an end-user pain point, with multiboot users top >> on the list of the injured. > > I fully agree: whatever solution we found, it has to be shared across > all distributions.Yes although not merely shared. But designed and agreement by. Otherwise this becomes worse than the linux multiboot situation, which today is pretty much a broken mess in which linux distributions break the bootability of the existing linux OS installation, and do so by default. It''s an ironic case where a linux distro is friendly to co-existing with Windows and OS X, but typically is downright hostile to fellow linux OS installations. Now if we want to admit that the different distros are in effect all hostile competitor OS''s to each other, then I guess a free for all where an open filesystem like Btrfs effectively becomes proprietary due to highly complex and variable layouts required to support snapshot system rollbacks is what we''ll just have to expect. In which case multiboot on Btrfs is dead in the water. Each distro would have to have their own volume, not their own subvolumes. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html