You still have a few misconceptions regarding BTRFS it's benefits I think.
Re. backups and partitioning:
Re. Snapshots (or subvolumes) and their size:
*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.
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.
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.
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.
Comment