BTRFS usage- Adding devices, moving data, converting to RAID1, all without rebooting

[oshunluvr]

You still have a few misconceptions regarding BTRFS it's benefits I think.

Re. backups and partitioning:

Having @ and @home on the same partition but in separate subvolumes does not mean when you backup @ you are also are forced to backup @home or vice versa, quite the contrary. If you look above at my instructions you'll see I explicitly describe making snapshots and send|receive actions for @ and @home separately. This is of course, unless you're not using BTRFS features to make your backup. In that case you are restricted to whatever backup method you are using. If you make a backup as I describe, you backup each individual subvolume. Having @ and @home on separate partitions has zero effect on this operation. Using BTRFS eliminates the need to backup entire partitions, is easier and faster than any other backup method I've ever used, and removes the need for arcane backup configurations to avoid backing up undesired folders. You simply make a file system level copy of the install subvolume and your backup can be bootable. Try doing that with rsync.

By keeping @ and @home on separate partitions you are eliminating one of the benefits of BTRFS - shared free space. To put it bluntly: partitioning is an old-school and out-of-date method of segregating data. BTRFS is an advanced file system that eliminates this requirement. In fact, BTRFS does not need a partition table at all. BTRFS can occupy the entire space on a device. For example, you need only specify /dev/sda instead of /dev/sda2 and the whole drive is used by BTRFS. However, at this time there is no way to boot to a whole-device BTRFS file system so partitioning is needed for a boot disk and swap is still best in a partition. My server has 4 data drives: two of them are whole device BTRFS file systems, the other two are set up as bootable so they have partitions for grub.

Re. Snapshots (or subvolumes) and their size:

At this time, there is no recognized method to determine the actual size of a snapshot* other than checking free space, deleting the snapshot, and checking free space again. The snapshot, when initially taken, is size zero. The size it occupies will grow as you make changes to the original (snapshot source) subvolume. The standard filesystem "properties" by itself does not show the size of the snapshot or reveal how much space will be freed by deleting it. This same restriction applies to any subvolumes co-located on the same file system. One must do the math, as it seems you have discovered. Note that standard old-school size reporting tools do not correctly reflect the actual space occupied by a BTRFS file system. You must do a "filesystem df" command. Assuming you wanted the size of your root filesystem, the command would be "sudo btrfs fi df /" ("fi" being short hand for "filesystem").

BTRFS occupies and separates data, metadata, and system space on a volume and the fi df command is only true indication of actual space occupied. Not the the occupied and free space indications are of the file system not the a particular subvolume. So if @ and @home reside on the same file system as separate subvolumes, the output of "fi df /" and "fi df /home" would be the same. This is due to the fact that both subvolumes have full access to all the file system's free space so naturally the same amount available is reported.

*A BTRFS feature - "Quota Groups" can, if properly enabled, can properly determine subvolume sizes. However, it is still a buggy and partially enabled feature and is not recommended for production use.

IMO, if you're not going to use two of the primary benefits of BTRFS why use it at all? Using a single partition and subvolume send|receive as a backup or data transfer method lead to functionality that EXT4 doesn't offer, like snapshots, shared free space, bootable backups with only a few simple commands, relocation of data, adding or subtracting devices from a single filesystem and all this without unmounting or even stopping use of the data.

[GreyGeek]

Oshunluver,
I've been thinking about backups and "send & receive". My backup to a second HD was done by formatting that HD with Btrfs and then mounting it on a new directory, /bkup. Then I mounted the live system on /mnt.

Then as root I created an ro snapshot for @ and @home:

btrfs su snapshot -r /mnt/@ /mnt/snapshots/@_bkup
btrfs su snapshot -r /mnt/@home /mnt/snapshots/@home_bkup

Then I did the send and receive between my HD on /mnt and the external HD on /bkup.

btrfs send /mnt/snapshots/@_bkup | btrfs received /bkup
btrfs send /mnt/snapshots/@home_bkup | btrfs received /bkup

Question: Why not just snapshot them directly to /bkup? The docs speak of using ssh for secure transfer between WAN devices but what about LAN or local devices? By mounting the external HD to /bkup I am putting it into the local fs.
I'm too sleepy to try it now but I will tomorrow..

[oshunluvr]

A "snapshot" can only exist on the same device as the source subvolume. Technically, when you execute "send|receive" on a snapshot, it's not a snapshot on the receiving end. It's now a copy of a subvolume.

Remember; a snapshot does not actually contain any data, it simply holds the current state of inodes of data that already exist in the file system. Thus when created, a snapshot occupies no free space (no data space anyway). As the data referenced by the snapshot's inodes are released (deleted) from the source subvolume, they remain in the snapshot, thus no data space is freed on the device.

When doing send|receive, the inodes don't transfer to another device, the receiving file system assigns it's own inodes to the incoming data. Therefore, the received volume is now a subvolume on it's own and not a snapshot.

Yes, you can transmit a subvolume via any method that you can normally transfer data through. Although the receiving device either has to be btrfs or you have to send the snapshot as a file and restore it to a btrfs file system to access it.

[GreyGeek]

A "snapshot" can only exist on the same device as the source subvolume. Technically, when you execute "send|receive" on a snapshot, it's not a snapshot on the receiving end. It's now a copy of a subvolume.

Ah, hence the reason why the send of @bkup took about 15 minutes and the send of @home_bkup took about 30.

Remember; a snapshot does not actually contain any data, it simply holds the current state of inodes of data that already exist in the file system. Thus when created, a snapshot occupies no free space (no data space anyway). As the data referenced by the snapshot's inodes are released (deleted) from the source subvolume, they remain in the snapshot, thus no data space is freed on the device.

When doing send|receive, the inodes don't transfer to another device, the receiving file system assigns it's own inodes to the incoming data. Therefore, the received volume is now a subvolume on it's own and not a snapshot.

Yes, you can transmit a subvolume via any method that you can normally transfer data through. Although the receiving device either has to be btrfs or you have to send the snapshot as a file and restore it to a btrfs file system to access it.

Ah, OK. (I told you I have a thick skull! And, it points out that one really doesn't have to know btrfs to use it. Just follow the man pages. )

When I put in that 2nd WD HD in the DVD Caddy and format it, I wll mount it as "/dev/sdb1 /bkup" after I that line in fstab, using that HD's uuid. I'm going to do that rather than do a btrfs add to pool it with sda1's subvolume. That way I can unmount it when I am not using it. I'm also going to continue using the WD USB 320Gb Passport HD as a bkup destination like I've been doing, until it dies, which I suspect will be "real soon" if the first one is any indication.

Thanks, Oshunluver!

[oshunluvr]

This morning, I did a fresh set of backups to a secondary HDD from my SSDs (2x250GB btrfs file system) for KDEneon and Kubuntu 16.04 and their respective homes - 4 subvolumes in all. I then deleted a few old snaps I had in a folder.

Right now df says:

/dev/sdc3         460G  142G  312G  32% /

fi df shows:

stuart@office:~$ sudo btrfs fi df /
[sudo] password for stuart: 
Data, RAID0: total=387.88GiB, used=138.63GiB
System, RAID1: total=32.00MiB, used=48.00KiB
Metadata, RAID1: total=5.00GiB, used=1.07GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

It will be interesting to see how the usage grows. I intend to keep the snapshots and start doing incremental backups. I haven't booted to 16.04 in months so it's not going grow, but KDEneon will no doubt.

[GreyGeek]

This morning, I did a fresh set of backups to a secondary HDD from my SSDs (2x250GB btrfs file system) for KDEneon and Kubuntu 16.04 and their respective homes - 4 subvolumes in all. I then deleted a few old snaps I had in a folder.

Right now df says:

/dev/sdc3         460G  142G  312G  32% /

fi df shows:

stuart@office:~$ sudo btrfs fi df /
[sudo] password for stuart: 
Data, RAID0: total=387.88GiB, used=138.63GiB
System, RAID1: total=32.00MiB, used=48.00KiB
Metadata, RAID1: total=5.00GiB, used=1.07GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

It will be interesting to see how the usage grows. I intend to keep the snapshots and start doing incremental backups. I haven't booted to 16.04 in months so it's not going grow, but KDEneon will no doubt.

That will be interesting to watch.

With this i7 8GB Acer V30771G running NVidia GT650M and a new 750GB HD, I have installed EVERYTHING I ever had on my Linux distros, putting on data dating from the 1980s and my Turbo Pascal Days. I have Steam, Obiter 2010, the IQAN dev tool, and I've put on Flight Gear and a ton of Linux games I've played in the past. I even have Penquin Pinball! I looked at Pingus and decided my grandson would hate it. I've installed PostgreSQL 9.5 and the Qt 5.8.0 SDK from qt.io, and loaded my Qt apps from work into it. Those work files had a 2008 date on them. When the DVD Caddy comes and I put in the WD HD this laptop will be the most powerful computer I've ever run. And it was made in 2012.

[jlittle]

It seems to me that btfrs send of a subvolume is the btrfs way of making an image of a partition.

1. Is that correct?
2. Is the format portable? By which I mean, can the output be stored, and be received on another machine?
3. ... or the same machine, some time later?
4. Is the format efficient, or would it benefit from compression?
5. Is the there any other way of imaging a subvolume?

I've googled the above, and I'm not sure about 1., 2. seems yes, but I think so only because the wiki publishes the format, 3. I think so, 4. I don't know, and 5. I've no idea.

[oshunluvr]

It seems to me that btfrs send of a subvolume is the btrfs way of making an image of a partition.

1. Is that correct?

Not really - partitions exist in a different way than subvolumes. Subvolumes are much more easily manipulated. Subvolumes are a way to segregate data without partitioning. BTRFS doesn't actually require a partition table (partitioning) at all. A BTRFS file system can exist on an entire device - as in formatting /dev/sdb rather than /dev/sdb1 - and on multiple devices simultaneously, similar to LVM or RAID.

I think the primary cause of the confusion here is caused by the use of incorrect terminology. You don't actually mount or "image" or duplicate a partition. Partitions are simply walls on your device that separate it into sections. What you actually mount or image are "file systems". Your hard drive (any block device, really) can be divided by partitions. In these partitions, you create file systems (AKA formatting). You can then put files on the file systems. Now if you have 3 partitions on a hard drive and each one holds a file system, data (files) cannot move across the partition boundaries except at the user level - copied from one file system to another. Most file systems require a partition table because they can only exist within, and fully occupy, the boundaries of a partition.

BTRFS is an advanced file system that adds a feature called subvolumes that allow you to separate data into logical sections within a single file system. When using BTRFS, you can divide a single file system (whether it's on a partition or not is irrelevant) into subvolumes, Subvolumes can be mounted just like individual file systems (partitions). When they are - they behave like a partitioned file system - data does not move across subvolume boundaries. However, you can also mount the root or main file system. Doing this reveals the individual subvolumes. A snapshot is a way to have the same data (files) accessible in more than one subvolume. At creation, a snapshot (a way to create a subvolume by copying an existing subvolume) is an exact duplicate of the source subvolume.- all the files are the same in both. However, if you add, delete, or edit a file in the source subvolume the same changes do not occur in the snapshot subvolume. With a snapshot, you have the same data accessible across subvolume boundaries. This may change as the data is manipulated - much different than a partitioned file system.

So the answer to the above query is no, no one actually ever makes an image of a partition. You are actually making an image of a file system. If you're using BTRFS you can separate and relocate your data by using subvolumes and transmitting them. Using another file system, you would have to image the entire file system, replicate the partition it came from (same exact size, etc.) and then restore it, or in many cases, the image software does the re-creation of the partition boundaries for you. With BTRFS and subvolumes, the size of the file system and it's partition boundaries (if there are any) are irrelevant - excepting, of course, the receiving file system must have enough free space to accept the subvolume.

2. Is the format portable? By which I mean, can the output be stored, and be received on another machine?

Absolutely and in fact easily. You can send|receive a subvolume directly to/from BTRFS file systems or you can send a subvolume to a file and transfer it in the same way you could any file. You cannot access the data when it's in a file, you must "receive" the subvolume on a BTRFS file system before accessing the data again.

3... or the same machine, some time later?

Yes, but I'm not sure what you have in mind here. In most cases, you can backup or "save" data by simply taking a snapshot.

4. Is the format efficient, or would it benefit from compression?

It's compressible with a mount option. File performance in some cases is historically somewhat less than other file systems, but IMO the advantages out weigh any slight reduction in speed. Often, these sort of test numbers don't reflect real-world usage anyway. One example is that you can take a snapshot, send|receive it to a backup drive, add or remove another partition or drive to/from your BTRFS file system, all without stopping the use of that file system. Live, on-line, backups and adding-subtracting drive space while still using your computer. The term "efficient" has many meanings.

5. Is the there any other way of imaging a subvolume?

Again, I'm not sure what you have in mind here. Snapshots are, in a sense, subvolume images and can be transmitted. I suppose you could image, in the more traditional way, an entire BTRFS filesystem but I can't think of a reason why you would. It's simpler and much less work to use the subvolume snapshot and send|receive features.

A use case I could think of is wanting to copy a subvolume from one computer to another when no network connection was possible. On computer A, you could "send" a subvolume to a file, then copy it to a thumb drive or CD-ROM. On computer B, you would then "receive" the subvolume from the thumb drive or CD-ROM to a BTRFS file system. You could actually format a thumb drive or USB drive with BTRFS and send|receive to it, but the BTRFS developers advise against doing that because the USB subsystem is not reliable enough to handle bit level transfers like BTRFS does, so you could corrupt your data.

I've googled the above, and I'm not sure about 1., 2. seems yes, but I think so only because the wiki publishes the format, 3. I think so, 4. I don't know, and 5. I've no idea.

<Chortle>

[jlittle]

Thank you for your long reply.

Not really -

I was thinking from a use case of "I want to back up my 16.10 install, in case of complete loss of machine (say fire, or theft)". Sure, I can back my data, and reinstalling Kubuntu is easy, but I configure a lot, use apt install a lot, sometimes add-apt-repository a lot.

Previously, I would image my root partition onto a backup drive. Now, I can image the btrfs partition, but I may have several installs in different subvolumes, so that's not the same. I was thinking, does btrts subvolume send -f suit that use case?

Hmm, I suppose I'd be better to put a btrfs file system on my backup drive, so that I can do incremental backups. But my backup drives have backups from other systems, like my family's windows laptops, so are formatted NTFS. (I tried doing incremental backups with rsync some years ago, but with NTFS it was a mess.)

[oshunluvr]

Thank you for your long reply.

Yeah, I got a bit windy, but I wanted to get all the info in there.

BTRFS send and receive are applied only to subvolumes, not an entire file system. So "send -f" sends a subvolume to a file and "receive -f' restores that file as a subvolume to a BTRFS file system. On the case of multiple installs on a single file system like I have, you would need to send|receive each subvolume separately. I don't see any reason why you couldn't image the entire BTRFS partition like you are now if that's the best solution.

You don't say it, but I assume the backup drive you refer to is a USB device. As I said before, the BTRFS devs do not recommend using send]receive over the USB subsystem. Likely, they're being over-cautious. Personally, I wouldn't trust NTFS for backups either, but that's just me.

I see a couple options right away: The likelihood of your computer actually blowing up are very slight. So the simplest backup solution is to use "send -f" to make copies of your subvolumes and copy the backup subvolume files to the USB drive.

Slightly more complicated, but not too much so; If you kept a backup on the PC itself, you could still do incremental backups on the PC itself, then do the send -f and copy to the USB drive periodically. That way you'd have a "live" backup on the PC's for easy access but still have a "all blowed up" copy on the USB drive.

Another idea but more work; You could partition the backup drive leaving the NTFS partition as the first partition, thus all your Windows PCs could use the backup drive. Copy the backup subvolume files to the NTFS partition, and restore (receive -f) them to a BTRFS file system on the USB drive. Then your backup files are accessible if desired. You wouldn't have to do the receive operation until you wanted to access the files.

Also, you can get a low profile USB thumb drive of 32,64, or 128 GB for less than $20-30, leave it in the PC, and use it to hold the copy of your install subvolume, while using the USB backup drive to backup your /home in the traditional way.

Which solution works for you will depend on your fault tolerance and willingness to spend the time doing it. In your case, maybe BTRFS isn't the best solution given your mixed OS environment. You could still use BTRFS on your PC but rely on other methods for backups. Also, I agree, rsync can be a mess.

[GreyGeek]

I deleted Snapper and ...

its snapshots.

The primary reason is that, after due consideration, I don't think they are necessary. They exist in two locations: /.snapshots and /home/.snapshots. Both are accessible without mounting the fs on /mnt. Neither are preserved in my btrfs /mnt snapshots. And, I can extract files from my /mnt mounted fs using mc just as easily as I can do the same from a snapper snapshot. I was, effectively, wasting disk space using snapper and keeping my read only backup snapshots on /mnt/bkup/snapshots. Keeping a copy of my system on a 2nd HD is more secure than in a local snapper snapshot. Farewell, snapper!

[oshunluvr]

After lots of playing around with BTRFS. I've decided the simplest approach is the best for me. My primary BTRFS file system is on two Samsung SSDs. On there reside my two current installs and homes and a subvolume named @snapshots. I've added the root volume to my fstab so the whole drive is mounted at /subvol and @snapshots is mounted at /snapshot. I then have a BTRFS file system for backups on a hard drive mounted at - strangely enough - /backup.

My simple method is to keep all snapshots on /snapshot. That way they're all easily visible and together. Since they're all on the same mount point I have to use unique names for them which prevents accidental confusion of what is what. So here's how those three mountpoints looks now:

[FONT=monospace][COLOR=#54FF54][B]
stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]/mnt/samsung[/B][/COLOR][COLOR=#000000]$ ll /subvol/[/COLOR]
total 4
drwxr-xr-x 1 root root 262 Apr  6 13:44 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 124 Feb 27 14:40 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr  9 09:42 [COLOR=#5454FF][B]@KDEneon[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  38 Apr  1 09:30 [COLOR=#5454FF][B]@KDEneon_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 262 Dec 13 08:08 [COLOR=#5454FF][B]@Kubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  32 Dec 22 17:05 [COLOR=#5454FF][B]@Kubuntu_16_04_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root   0 Apr  9 09:41 [COLOR=#5454FF][B]@snapshots[/B][/COLOR][COLOR=#000000]/[/COLOR]
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]/[/B][/COLOR][COLOR=#000000]$ ll /snapshot/[/COLOR]
total 4
drwxr-xr-x 1 root root   0 Apr  9 09:41 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr  9 09:42 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/
[/COLOR][/FONT][FONT=monospace]drwxr-xr-x 1 root root 270 Apr 1 13:21 [/FONT][COLOR=#5454FF][FONT=monospace][B]@KDEneon1[/B][/FONT][/COLOR][COLOR=#000000][FONT=monospace]/[/FONT][/COLOR]
[FONT=monospace]drwxr-xr-x 1 root root 270 Apr 1 13:21 [/FONT][COLOR=#5454FF][FONT=monospace][B]@KDEneon2[/B][/FONT][/COLOR][COLOR=#000000][FONT=monospace]/[/FONT][/COLOR][FONT=monospace][COLOR=#000000]
[/COLOR][/FONT][FONT=monospace]drwxr-xr-x 1 root root 38 Apr 1 09:30 [/FONT][COLOR=#5454FF][FONT=monospace][B]@KDEneon_home1[/B][/FONT][/COLOR][COLOR=#000000][FONT=monospace]/[/FONT][/COLOR][FONT=monospace][COLOR=#000000]
[/COLOR][/FONT][FONT=monospace]drwxr-xr-x 1 root root 262 Dec 13 08:08 [/FONT][COLOR=#5454FF][FONT=monospace][B]@Kubuntu_16_041[/B][/FONT][/COLOR][COLOR=#000000][FONT=monospace]/[/FONT][/COLOR][FONT=monospace][COLOR=#000000]
[/COLOR][/FONT][FONT=monospace]drwxr-xr-x 1 root root 32 Dec 22 17:05 [/FONT][COLOR=#5454FF][FONT=monospace][B]@Kubuntu_16_04_home1[/B][/FONT][/COLOR][COLOR=#000000][FONT=monospace]/[/FONT][/COLOR][FONT=monospace]
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]/[/B][/COLOR][COLOR=#000000]$ ll /backup/[/COLOR]
total 16
drwxrwsr-x 1 root   backup 290 Apr  3 21:41 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root   root   286 Apr  9 09:42 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root   root   270 Apr  3 21:49 [COLOR=#5454FF][B]@KDEneon1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root   root    38 Apr  4 08:08 [COLOR=#5454FF][B]@KDEneon_home1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root   root    48 Dec 11 07:49 [COLOR=#5454FF][B]@Kubuntu_14_04_home_ro[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 stuart stuart  86 Dec 11 09:06 [COLOR=#5454FF][B]@Kubuntu_15_04_home_ro[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root   root   262 Apr  4 09:53 [COLOR=#5454FF][B]@Kubuntu_16_041[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root   root    32 Apr  4 09:04 [COLOR=#5454FF][B]@Kubuntu_16_04_home1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 stuart stuart  26 Dec 26 13:21 [COLOR=#5454FF][B]@other_backups[/B][/COLOR][COLOR=#000000]/[/COLOR]
[/FONT]

I have also added the alias "bt" to my bash_aliases file for "sudo btrfs"
The simplicity kicks in when I'm doing snapshots:
bt su sn -r /subvol/@KDEneon /snapshot/@KDEneon3

I usually do "sudo -i" when I'm doing send|receive so its:
sudo -i
btrfs send /snapshot/@KDEneon1 | btrfs receive /backup

The simple mount points help keep it straight in my old memory and keeping the snaps in one location makes accidental duplication less likely. You might notice from the above listing I used to add "_ro" when I did a read-only snapshot, but I've stopped doing that. Now I use the trailing number on the snapshot name to keep multiple snapshots of the same subvolume for incremental backup purposes which also indicates it's read-only to me - since it has to be for send|receive.

[GreyGeek]

Amazing! Even to the name of the backup (/backups) our approaches are essentially identical! I hope your mind is great, because we think alike! (Yours has to be, because mine is not)

[Snowhog]

I have also added the alias "bt" to my bash_aliases file for "sudo btrfs"
The simplicity kicks in when I'm doing snapshots:
bt su sn -r /subvol/@KDEneon /snapshot/@KDEneon3

Expanded, this would be sudo btrfs su sn -r /subvol/@KDEneon /snapshot/@KDEneon3 My confusion is sudo btrfs su. Isn't the use of su redundant?

[oshunluvr]

Expanded, this would be sudo btrfs su sn -r /subvol/@KDEneon /snapshot/@KDEneon3 My confusion is sudo btrfs su. Isn't the use of su redundant?

Sorry Paul, I defaulted to btrfs shorthand. most btrfs options can be shortened to their first few letters, so

btrfs su sn

translates to:

btrfs subvolume snapshot