On Mon, May 3, 2010 at 3:46 PM, Dieter Plaetinck <dieter@xxxxxxxxxxxx> wrote: > > I was the one who proposed aif --expert on the forums ;) heh yeah, i was too lazy too look it up, and it was all a part of my secret plan to get you to back me up :) > Did I understand it correctly that you can fix the "cannot promote a > snapshot to become the default subvolume" problem by just using a > specific named subvolume instead of the default? i.e. it's basically > just a name change, nothing drastic? there isn't really a problem here, i just haven't built it into the hook yet. what i (we) really need is to decide on an appropriate "subroot" structure. basically, i don't think we should install the system into the default, "." (the original default subvolume is a period), subvolume. if we do this it makes it messier to move root/home/var/whatever snapshots around. we should reserve the "." subvolume for our implementation specifics, and install the system into say /root/__active as i suggested before. more reasons for the above is that subvolumes behave like folders and are nestable, and you cant remove a subvolume that has another inside it. the nested one must be moved outside the parent, or removed first. my goal was to have all snapshots "under" or "outside" the root, so the user cannot see or mess with them, and snapshots are clean and leave no artifacts (like empty folders where nested subvolumes used to be [snapshots are not recursive]). all of this i have gathered from practice. subvolumes can be mounted two ways via a mount option: 1) subvol=<subvolume_name> 2) subvol=<subvolume_id> 1 can only be used if the subvolume is in the root of the FS, i.e. /__active would work, but /root/__active would NOT... the mount option cannot have slashes and i don't know if this will change. 2 can be used to mount ANY existing subvolume, but you must know it's internal id, and the tools for this are only available in 2.6.34+ via the command "btrfs subvolume list" there is also the option in 2.6.34+ to use the command "btrfs subvolume set-default" to make any subvolume the new default (via it's internal id not its [folder] name), and then the mount option [subvol] is not needed. we have a couple options that are basically the same except for implementation: 1) use a naming scheme and keep the __active (default) subvolume in the root in this setup, "promotion" of any snapshot to default simply means removing the old /__active, and snapshotting the target subvolume (say /__rollback) to /__active. this would require "subvol=__active" to be added to the rootflags at EVERY boot, and __active MUST reside in the root (since we are booting it by name and not id). this option has the advantage of working with older kernels and versions of btrfs that lack the ability to define a new default or mount by id, but is less flexible. 2) use a naming scheme and use setting defaults and ids for booting this is basically the same result as above, but we can put __active [and others] wherever we want, like /root/__active. we would then boot it via it's internal id (using rootflags/mount options) or by declaring __active the new default. depends on a 2.6.34+ kernel, but its more flexible in how we lay out the "subroot". both depend on mounting the "." subvolume somewhere after the fact (via fstab/inside initcpio hook) for listing/snapshotting/moving/renaming operations. bleh, apologies for the length, trying to be thorough. > About the implementation in aif, it's doable. > after all, i managed to implement LVM, which is kinda similar (you can > put PV's on partitions/devices, use multiple PV's in one VG, put > multiple LV's in 1 VG, and then make normal filesystems (and define > mountpoints) on single LV's). i will have to take a closer look then. i have never setup or used LVM before; but that all sounds pretty similar; if anything it should be simpler/cleaner/faster in BTRFS? we'll see. > About the "creating snapshots immediately after performing an > installation" idea: > seems like an interesting feature, which could happen at the end of the > installation process (no reboot needed) that would work too, and it would be just as easy to build it into the [initcpio] hook. users could clone this snapshot and setup totally different systems, switchable at boot time (if one wished). my goal was just to get the ball rolling on this, and generate some interest and brainstorm use cases. with some direction i can update the mkinitcpio-btrfs hook to whatever standards for a future merge into the core repositories. this could be updated in conjunction with AIF. my next updates to the hook were going to introduce an /etc/btrfs.conf file (to be included into the initcpio image), and this config file would control the various operations of the hook. however, i'm not sure what all the rules are here... with great power [and flexibility] comes great responsibility. C Anthony
