hello, i maintain an unofficial btrfs initcpio hook in AUR: http://aur.archlinux.org/packages.php?ID=33376 the hook provides rollback support among other (future) features. hook is also required for anyone using a multi-device btrfs setup. i would like to start/be included in discussion involving btrfs integration into AIF, and other aspects of Arch. i think it would be nice for users to be able to have the option to use the new filesystem by default-ish, and have the tools needed to work with it. specifically, it would be really neat to have "rollback" support in a "rolling" distro. people would likely be more willing to ride the edge of the testing repo if they knew they could simply reboot and all could be well again when things did break. right now, the rollback feature provided by the hook is volatile, but this is only an implementation detail. what i mean by this is once you rollback, you CANNOT promote the "rollback" subvolume to be the new "active" (default) subvolume; you must fix the default subvolume manually and reboot again. anything you do in rollback mode will be lost on the next rollback. this is something i intend to change, but i need some input from other developers. what i propose is to do away with installing the system onto the default subvolume (like a typical installation); system will be installed to it's own subvolume (/root/__active). something like this: . ├── home │ ├── __active │ ├── __rollback │ ├── snap_11-11-1111_11-11-11 │ └── snap_22-22-2222_22-22-22 └── root ├── __active ├── __rollback ├── snap_11-11-1111_11-11-11 └── snap_22-22-2222_22-22-22 this is the "subroot" structure; underneath your / [root]. "." is the original default subvolume. /root/__active is your "primary" (default) system. /root/ __rollback is a volatile copy of a /root/snap_XX (you boot into this [__rollback] when you "rollback"). since snap_XX gets copied to __rollback... if you decide you want to ditch your changes to __active (since it's messed up anyways), you just replace __active with __rollback (delete/rename), reboot, and voilà! your system's __active subvolume works again, and none of your snapshots got messed with. same logic for /home/__active and /home/__rollback (and snap_XX) except you wouldn't have to reboot... maybe we can create login manager ([xkg]dm) hooks to remount your home folder with a "rollback" on the next logout or something? who knows. we could take a snapshot after install (on the very first boot), called "__original" or something, then users would always have a copy of their system immediately after installation; they could revert/use/delete that if they wanted to at any time. however, this setup would require mounting the default subvolume somewhere else in order to gain access to the "subroot" structure, but it would guarantee that you could not destroy your system no matter what you did to your / [root]. any ideas on this? my attempts to generate interest in the forums are falling on deaf ears so i thought i'd try my luck here. thanks, C Anthony
On 05/03/2010 12:13 AM, C Anthony Risinger wrote:
hello,
i maintain an unofficial btrfs initcpio hook in AUR:
BTRFS is not marked stable by the developers yet, its dangerous to include it in the interest of arch newbies. A disk crash may spoil the impression of Arch. In my opinion, we should wait some more time till the developers of BTRFS release a stable version to include it into AIF. -- Nilesh Govindarajan Site & Server Administrator www.itech7.com मेरा भारत महान ! मम भारत: महत्तम भवतु !
On 05/03/2010 12:40 AM, Nilesh Govindarajan wrote:
BTRFS is not marked stable by the developers yet, its dangerous to include it in the interest of arch newbies. A disk crash may spoil the impression of Arch.
In my opinion, we should wait some more time till the developers of BTRFS release a stable version to include it into AIF.
+1 Till Ext4 would fill the gaps -- Regards, Gaurish Sharma www.gaurishsharma.com
On Sun, May 2, 2010 at 2:19 PM, Gaurish Sharma <contact@gaurishsharma.com> wrote:
On 05/03/2010 12:40 AM, Nilesh Govindarajan wrote:
BTRFS is not marked stable by the developers yet, its dangerous to include it in the interest of arch newbies. A disk crash may spoil the impression of Arch.
In my opinion, we should wait some more time till the developers of BTRFS release a stable version to include it into AIF.
+1 Till Ext4 would fill the gaps
i agree it probably should not be visible by default (one suggested option was a flag to AIF, like aif --expert), but the tools (hooks/etc.) need to be developed and stabilized too. there are many users who want to try BTRFS regardless of the risks, and i think we should let them test other integration points along with it. what good is a stable FS if the tools to use it are alpha and buggy for 1 year afterward? that leaves a worse impression than letting advanced users, aware of the risks, use the tools and provide feedback. in my opinion we need to let AIF/etc. integration mature along with the FS itself. this way when BTRFS is marked "stable" the tools will be ready as well and it will be a minor transition. personally, i've been using btrfs for almost a year without issue, and i see much positive feedback from others around the net as well. my main issue is that btrfs is advanced and we have much to think about the way we want to include it. rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model. additionally, ext4 developer (Tso) has been quoted as saying ext4 is little more than a bridge to BTRFS. in my opinion ext4 is of no interest. C Anthony
my main issue is that btrfs is advanced and we have much to think about the way we want to include it. rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model.
additionally its not as simple as other FS's. the subvolume/pooling aspect of btrfs means that if you wanted your /var to be compressed, your /home to be (insert mount options), and your root to be (insert mount options), all RAID10 across 4 devices... you would mkfs.btrfs ONCE, then create individual subvols for each. methinks w/o looking at AIF code that this is rather exotic compared to the partition-per-FS options currently available. i just think it's a good idea to start thinking about and integrating all of this now, as btrfs is evolving rapidly and there is a tremendous amount of community interest in it across all distros. btrfs was merged at .29, declared ready for early adopters in .32, and gaining interesting features + stability all the time. i believe it will be "declared stable" sooner than some may think. and rollback is super useful, and would be a natural addition to the Arch's rolling model... afiak the Fedora 13 rollback is mostly useless; the hook i have created is more featureful, which makes Arch the only distro truly supporting btrfs rollbacks :-) (not OOTB however...) C Anthony
On 05/02/10 15:27, C Anthony Risinger wrote:
rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model.
it could save one from pacman running out of disk space when installing something (which presently leads to unpredictable behavior that might necessitate a re-install). On the other hand, by keeping the older snapshot files (which take space), it's more likely that you do run into out-of-disk when you upgrade something in a way that's protected by a snapshot, and you have a different sort of problem to deal with then... -Isaac
in my opinion we need to let AIF/etc. integration mature along with the FS itself. this way when BTRFS is marked "stable" the tools will be ready as well and it will be a minor transition.
I could not say it better myself. It always takes a while until the 'experimental' flag is removed in the kernel, waiting until that happens means waiting too long. we should not apply our normal practices (package the latest stable releases) from normal software to kernel features. But I think we should only expose advanced (experimental) stuff to power users. I was the one who proposed aif --expert on the forums ;) So aif patches are definitely welcome. 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? then that sounds good to me, I don't know much about btrfs. [1] 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). It's just not very pretty, see http://bugs.archlinux.org/task/15640 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) Dieter [1] except that chris mason is an awesome dude who has contributed to uzbl.
On Mon, May 3, 2010 at 3:46 PM, Dieter Plaetinck <dieter@plaetinck.be> 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
On 05/05/10 19:10, C Anthony Risinger wrote:
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.
since we control the structure, why not the (slightly uglier) /root__active /root__rollback /root__20090807 /home__active /home__... just remove the slashes or replace them with some other character like dash or underscore. `ls` will still sort things alphabetically so there will still be some semblance of order for the humans, and it would behave nearly the same to the machine. And it will be easier for debugging purposes if all these subvolumes are accessible by name. (Do you think you can ask upstream whether they want to change or keep the restriction on slashes(i.e. volumes in subdirectories), in light of our '.' organizational ideas?) -Isaac
On Wed, May 5, 2010 at 6:28 PM, Isaac Dupree <ml@isaac.cedarswampstudios.org> wrote:
On 05/05/10 19:10, C Anthony Risinger wrote:
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.
since we control the structure, why not the (slightly uglier)
/root__active /root__rollback /root__20090807 /home__active /home__...
just remove the slashes or replace them with some other character like dash or underscore. `ls` will still sort things alphabetically so there will still be some semblance of order for the humans, and it would behave nearly the same to the machine. And it will be easier for debugging purposes if all these subvolumes are accessible by name. (Do you think you can ask upstream whether they want to change or keep the restriction on slashes(i.e. volumes in subdirectories), in light of our '.' organizational ideas?)
ah, yeah thanks, i meant to mention that too but got lost in the myriad of letters i had written :). this would work just fine, and has the benefit of working on pretty much any recent-ish kernel/btrfs version. the end user should never see any of this anyway. iirc, this is how fedora does it (something like yum_snapshot_20090807). but fedora installs into the default "." subvolume, so each time you take a snapshot you get a bunch of empty folders from previous snapshots (the snapshot yum_snapshot_20090808 would have an empty folder yum_snapshot_20090807 [snapshots not recursive]); we can stop this by not installing into the "." subvolume and using an actual mount point for operations, plus it keep the real root "device" (root__active) nice and clean. as for upstream, they are pretty receptive to changes right now. im not sure if the slash thing is a limit of the mount command/something else, or just was not implemented. afiak, the <id> mounting was implemented to replace the name mounting [and for setting a new default], i'm not sure if <name> mounting will be dropped or not. also even if they did implement, we prob wouldn't see it until 2.6.35 :(. any other ideas besides rollbacks and an original snapshot that btrfs could be used for? C Anthony
On Wed, 5 May 2010 18:49:44 -0500 C Anthony Risinger <anthony@extof.me> wrote:
any other ideas besides rollbacks and an original snapshot that btrfs could be used for?
IIRC it supports data checksumming. about the whole snapshot/volume naming thing: do what you think is best. i cannot advise you because i don't know btrfs. however you mentioned compatibility with older kernels and older btrfs versions. i wouldn't worry too much about that, by the time we actually support btrfs, kernel .33 and such will be behind us ;) Dieter
participants (5)
-
C Anthony Risinger
-
Dieter Plaetinck
-
Gaurish Sharma
-
Isaac Dupree
-
Nilesh Govindarajan