Btrfs: Exploring its powerful filesystem subvolumes and snapshots

My hands-on experiments with some advanced Btrfs capabilities show why it's such a useful tool for Linux administrators.
Written by J.A. Watson, Contributor

This is the fourth post in the series about the btrfs filesystem. In the first post on this subject I discussed btrfs basics, showing how to create simple btrfs filesystems.

Btrfs hands on: My first experiments with a new Linux file system

In the second post, more on btrfs, I showed how btrfs filesystems can span multiple partitions and devices, and can be resized even while the filesystem is still mounted. In the third post, RAID and Redundancy, I discussed some of the advanced structural capbilities of btrfs.

Although I am giving quite a few details and examples in these posts, please remember that I am only trying to give an overview of btrfs functionality and use; the authoritative source for information remains the Btrfs Wiki.

There is one more aspect of btrfs filesystem creation and structure that I would like to discuss - subvolumes. 

But where to begin with subvolumes, that's a bit of a problem. Please bear with me in what follows, because I am struggling to find a clear and effective way to present this.

I've tried writing it with CLI examples, but that turns it into a long jumpy sequence of commands and explanations. 

I've tried writing it with GUI screenshots, but that comes out looking contrived and wasting huge amount of space to present very little information in a way that isn't terribly clear anyway. So I've finally decided that best way is to just write a description with a few blocks of CLI command sequences.  Fingers crossed... (hard to type that way!).

One thing is almost certain - btrfs subvolumes are sort of like a lot of things that you have worked with before, but they aren't really like anything you have worked with before.  

I find it useful to think of them is as "alternate restricted views" into a filesystem. Every btrfs subvolume has a corresponding directory in its parent filesystem, which is created when you create the subvolume itself.

You can copy things into that directory (which thus puts them into that subvolume), you can create other directories under that subvolume directory, and you can even create other subvolumes under it. The key here is that it looks and acts almost exactly like a "normal" directory. (Hint: try to remove a subvolume directory it with rmdir.)

Of course, there's not much interesting about some complicated new way to just make a directory, and fortunately that's not all there is to subvolumes. You can actually mount a subvolume in basically the same way that you have always mounted entire fillesystems, all you have to do is add "-o subvol=name" or "-o subvolid=ID" to the mount command or /etc/fstab. When you do this, the directory associated with the subvolume will be the top level of the mounted filesystem. That's what I mean by "restricted view" above.

Let's try a quick example to show what I mean.  I am starting here with a simple btrfs filesystem mounted on /mnt. 

    # mount /dev/sda4 /mnt

    # btrfs subvolume create /mnt/svol

    # btrfs subvolume list /mnt

        ID 256 gen 5 top level 5 path svol

    # ls -l /mnt

        total 0

        drwxr-xr-x 2 root users 4096 Dec  4 21:38 svol

    # cp /etc/motd /mnt/svol

    # ls -l /mnt/svol

        total 4

        -rw-r--r-- 1 root users 21 Dec  4 21:40 motd

    # umount /mnt

    # mount -o subvol=svol /dev/sda4 /mnt

    # ls -l /mnt

        total 4

        -rw-r--r-- 1 root users 21 Dec  4 21:40 motd

Do you see what happened there?  When I had the entire btrfs filesystem mounted, I could see the subvolume directory and I copied a file into that directory. 

But when I unmounted it, and then mounted the subvolume, that file was then visible at the top level, because the directory associated with the subvolume had been assigned to the mount point.  Equally important, but impossible to show here, is the fact that there is now no way for me to see or access anything above that subvolume directory. So I have an "alternate restricted view" of the btrfs filesystem.

Ok, while you're scratching your head over that, let me throw one more thing at you.  I can actually still mount the entire filesystem as well, and everything that is happening in this subvolume will be visible there, as well.  Check it out:

    # mount /dev/sda4 /data

    # ls -Rl /data


        total 0

        drwxr-xr-x 2 root users 4096 Dec  4 21:38 svol


        total 4

        -rw-r--r-- 1 root users 21 Dec  4 21:40 motd

Now, I'm not going to waste a lot of time on the rest of the manipulation, but I can add, modify or delete files in either one of these mount points, and the changes will immediately be visible in the other one. That's pretty impressive. 

At this point, I hope that experienced Linux administrators are starting to realize how useful and powerful this can be.

I would also point out that this is of course not limited to just one subvolume; as a trivial example you could just as easily create several more subvolumes, perhaps named as sv2, sv3, sv4 and so on, and mount each of them in different places, for different uses, but then still have the entire filesystem mounted as well, so that you could monitor and manage the contents of all the different subvolumes from one place.

Ok, so much for the basics of creating and mounting subvolumes. But there's more, and it's even better. One of the most useful features is the ability to take snapshots of subvolumes.  The command is amazingly simple:

    # btrfs subvolume snapshot /mnt/svol /mnt/snap

This will create a snapshot of the contents of subvolume svol, in a new directory called snap. In fact, it turns out that snap itself is a new subvolume. If you add a "-r" to that command, it will create a read-only snapshot of the subvolume.  Oh, and because btrfs is a Copy-on-Write filesystem, the snapshot initially consumes no additional disk space, and will only start to use space if/when its files are modified, or new files are created. Zowie!

Ok, one last thing before we finish with subvolumes. Another extremely useful feature, subvolume quotas. You can have quotas defined for subvolumes and groups of subvolumes, so you can ensure that one or more subvolumes do not consume all of the available space in a btrfs filesystem.

Well, I hope that wasn't too dense or too boring. Subvolumes really are one of the absolute key features of btrfs filesystems, and learning to use and manage them effectively is the key to getting some real benefits from btrfs.  Sorry that there weren't any pretty pictures this time...

Further reading on Btfrs

Editorial standards