BTRFS mkinitcpio hook

Question

UPDATE (6/10/10): http://bbs.archlinux.org/viewtopic.php? … 51#p772651
THIS POST DEPRECATED UNTIL I UPDATE IT, USE THE UPDATED POST ABOVE
available:
http://aur.archlinux.org/packages.php?ID=33376
this package will install a mkinitcpio hook intended for those who wish to have a single or multi-drive BTRFS file system as their / (root).  the hook will ensure that the chosen root device from the kernel command line is intact and safe to boot.  if root is not a BTRFS device, the hook is quietly skipped.
it requires btrfs-progs from here:
http://aur.archlinux.org/packages.php?ID=15635
hook supports both UUID or device based root names.  UUID is safer; the entire BTRFS array only has one UUID, so referring to it means no problems. use /dev/device/by-uuid on kernel boot.
hook supports hot spares by using a dummy, spare BTRFS file system to steal devices from as needed.  the spare pool can be referenced by label or UUID.**
hook supports automatic repairing of the array if possible, automatic dropping of missing/failed devices if possible, and booting the array to a degraded state (one or more devices missing) if possible.**
**NOTE: there are some bugs that may be in the hook/btrfs module/btrfs-progs that prevent raid1 (maybe others) arrays from being repaired (see http://pastebin.com/m5706f47f) however, this hook will work fine as is for single/multi-device arrays that are intact.  enable experimental options manually by editing options in the hook itself (/lib/initcpio/hooks/btrfs).  USE WITH CAUTION ON MULTI-DEVICE SETUPS.
the initramfs script can be seen here:
http://aur.archlinux.org/packages/mkini … btrfs_hook
its fairly commented, although there are a few things i'll point out for others who want to edit:
1) i plan to rework _btrfs_scandev() to be more flexible in the variables it produces.  that function simply parses "btrfs-show" and gleans valuable information from it.  it will be used to verify array states with certainty.
2) seems that btrfsctl does not have meaningful exit codes right now, do not rely, see _btrfs_register().
3) seems that after legitimately removing a device from an array (NOT using "missing" special keyword), the mount needs a "mount -o remout [mnt]" for the ***missing flag to be removed from btrfs-show.  not sure the ramification of this or if its necessary.
4) some or all of this functionality may someday be provided by module/kernel
needs work + comments
add "btrfs" to HOOKS in mkinitcpio.conf
Last edited by extofme (2010-06-10 06:09:10)

Answer 1

bleh, sorry about the late response, i usually subscribe to topics i create/join, i must have missed this one.
resi wrote:After minor problems with the mkinitcpio (lvm hook seems to conflict with the btrfs one) image and fstab (why do I have to specify the root fs there? its already mounted when fstab is examined)
i could be mistaken here, but initially your / is mounted read-only.  during the init process, one of the primary scripts issues a "mount -o remount,rw /" to remount the root device as read-write.  i _think_ using the mount command in this way (against a mount point and not a device) requires the mount point to exist in the fstab.
resi wrote:But what happens if I really screw it up? I'm on 2.6.33 (.2-1) and read about missing ioctl()s regarding btrfs, meaning I can't replace the "default" subvolume (whats the difference between a subvolume and a snapshot anyway?). Its also not possible to list available subvolumes/snpshots, meaning your script (or organizing snapshots in similar ways) is the only chance to keep track of them, right?
the inability to set the default subvolume is kind of a non-issue after i thought about it more, and some of the discussion on arch-general.  i plan to update the hook soon to allow the "promotion" of the rollback to become the new active subvolume.  ill do this by snapshotting your current / to a new subvolume called /__active, and then permanently booting into that [__active] instead of / or "." (a period is the default subvolume, like current directory).
there is no difference internally, whatsoever (AFIAK), between a subvolume and a snapshot.  its just a matter of context: a subvolume starts out empty (explicitly created via a command/etc.), and a snapshot starts out with content (COW operation against an existing subvolume, i.e. "copy")
yeah without the ability to list available subvolumes, we have to make up some structure, and assume everything goes well.  my script simply assumes anything within /snapshots is indeed a snapshot that can be copied (to /__rollback) and booted.  even if we can list subvolumes, we'll still need some kind of predefined structure (so the script knows which snapshots are bootable, and which are not, i.e. snapshots of /home are not bootable).
resi wrote:I guess a plain "mount -t btrfs /dev/xyz" will mount the "default" subvolume then.
correct.
resi wrote:
Once I really screw up I will have to boot into a snapshot, mount the default subvolume somewhere and restore it using a full copy from the snapshot (a la rsync --delete), then reboot and I'm back at the start again.
Is this correct?
unfortunately, without modifying the script, a manual copy is necessary :-( totally defeating the advantages of btrfs.  so, yes.  the problem is that the default subvolume itself cannot be replace by another... note this is different from SETTING the default subvolume.  i'm not sure if the real default subvolume ("." the period) will ever be replaceable/removable, i'd have to ask the btrfs list.  this is why i advocate installing your system into a subvolume FROM THE BEGINNING.  this gives us more flexibility.
resi wrote:Is there some way to permanently change the subvolume mounted by your hook (i.e. not running in a volatile snapshot, but actually drop the default one and always boot into a given snapshot until further notice - a new snapshot)?
this is actually how i intend to implement non-volatile rollback abilities in the hook.  instead of booting the default "." subvolume, my hook will ALWAYS boot the subvolume called "__active", located at /__active.  this way you can put whatever you want there, and it will be booted at the next reboot.  therefore, you can boot into rollback mode (essentially booting into /__rollback), update/add/remove whatever you want, and when your satisfied, you simply snapshot /__rollback to /__active and your done.  reboot, and your new __active will be in the same state as the point it was created in rollback mode.
does all this make sense?  i'm told i tend to over explain/complicate things :-).
resi wrote:Before every -Syu I have to check for kernel/xorg updates, read about them, check the mailing list, wait ... wait ... wait ... loose patience, give it a shot, recompile/reinstall the necessary stuff (at least I've got PKGBUILDs prepared) and hope for the best. With btrfs, this is just a non-issue. Or at least will be once the integration is better.
i hear ya.  i like the idea of riding the edge without the fear of being cut by it.  unfortunately, until btrfs is supported by grub2, kernel rollbacks aren't possible (you'd have to manually backup your old kernel+initrd).  something to keep in mind.
hunterthomson wrote:However, if I can just tell my clients to reboot into a snapshot "problem solved." Then I can spend the time to solve the problem, without the client siting around with a broken system.
bingo.  that is pretty much my primary motivation here... less time freaking out about down time/whatever; everybody wins.
hunterthomson wrote:Did you know Fedora 13 supports Btrfs Snapshotting and Roll-Back. Super cool.
i know they have some support but i haven't tried it; from what i've read, the support is pretty weak... you can get yum to create the snapshot by installing a package, but there is no utility to actually use them later on.  i could be mistaken as i don't use fedora, this is only what i've read.
what sucks is pacman doesnt have any ability to use hooks... i dont think we will see automatic snapshots by the package manager without a wrapper like clyde/powerpill/packer/etc.
C Anthony