BtrFS as a root file system
torriem at gmail.com
Sat Feb 1 23:51:01 MST 2014
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
More information about the PLUG