On 01/31/2014 05:27 PM, Robert Fleming wrote: > Send me the link. Got things started and working. Took a normal, non-btrfs VM, and copied its disk's contents to a new image that I formatted to btrfs. Then fixed up its fstab and grub, and booted on it (selinux is currently off as it prevented my first boot up, but maybe a relabel is all it needs will try soon). I did this mainly because I wanted a highly customized layout to start with, and I didn't want to do another install (internet isn't so speedy).
I started writing a script to do an automatic root snapshot. The first goal is just to snapshot the current running root into a "last good" snapshot that I can boot off of. And that worked out pretty well. I have it fix up the snapshot's fstab and add an entry to grub for it, which I keep in a separate /boot ext4 partition, which has some potential problems until some day when grub2 supports btrfs natively. Anyway it booted right up into the snapshot. Pretty cool. In my forthcoming write-up I'll post the script. I want to make it a bit more flexible and able to handle any subvolume scheme you have. Learned a few things: - everyone does btrfs subvolume layouts differently. My layout is partly influence by how Arch may do it (I think?), partly by how it would have been done under ZFS. Ubuntu has yet a different layout yet. - but if you don't have the btrfs layout quite right, you can actually change it from within by creating new snapshots, set up the way you want to, fix up fstab in the snapshot, add a grub entry for it (/boot is currently ext4 and separate), then boot into that, and then once in there, delete your old root. That's the beauty of snapshots. Copy-on-write volumes. Wonderful. - BtrFS subvolumes are hierarchical (have parent/child relationships), but referred to mainly by their path, which is in some measure based on where they are mounted or located, which may have nothing to do with the path of the parent fs. This provides a lot of flexibility that ZFS didn't have. Snapshots can be read-only, but to be bootable they really need to be read-write. In this way snapshots are really full subvolumes, just that they are essentially dedupped with another subvolume. Powerful concept. - yum-plugin-fs-snapshot is too naive to work with my layout, and actually doesn't run without a patch even though it's in the official Fedora repositories. I guess no one uses it. I might fix it up to work with a bunch of different layouts and submit patches. Maybe this is a useful thing, maybe it's not. - snapshots of the root file system might be somewhat inconsistent. If MySQL is running when its database is snapshotted, then the files in the snapshot might not be clean. It's a tricky issue, especially on production machines. And if my present goal is to get a snapshot of a known-to-boot configuration, I can't do it before the boot process is completely finished, in case it hangs later on in the process. TL;DR. I was able to take a snapshot of the whole root filesystem, and then boot into that snapshot. Then go back to the original root, delete the snapshot. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
