So you want to try BTRFS?

[GreyGeek]

Then allow me to make some recommendations that I've accumulated from my own experience, comments from Oshunluver, dbil, Snowhog and others, and around the web.

Recommendations

Many people have reported years of btrfs usage without issue, and this wiki page will continue to be updated with configuration recommendations known to be good and cautions against those known to cause issues.

1. Typical usage, unless you are Oshunluver, is to use one HD and give it entirely to sda1, unless you need a swap partition. In that case make the swap equal to your RAM +5%. Use the rest of the partition for Btrfs. Select Btrfs and assign / to the sda1 partition. Although you could, do not use sda, use sda1. IOW, assign Btrfs to a partition, not the disk. If you have two HDs dedicate one to archiving snapshots, mounting it when necessary, then unmounting it when done.
2. Not using compression gives you the most speed and least chance for corruption. I've yet to use compression but when I install Neon 18.04 I will try it out. Do you need compression? Then zlib seems to have fewer issues than lzo. Zstd is between them, with both speed and compression, and is newer. Many pros are now recommending zstd, which is what I am going to use.
3. Do not use quotas/qgroups.
4. Manual snapshotting is easy and affords the most control. Insist on using Snapper? Turn the "TIMELINE" feature OFF and make SINGLETON snapshots only. Want a GUI app instead of a CLI app? Use Timeshift. IF you use Timeshift and later decide to remove it FIRST delete ALL the snapshots you made with it. Do not install "apt-btrfs-snapshot" unless you are running your system on 10TB HDs. You'll blow through your disk space in the wink of an eye. Every time you use the apt command it will create two snapshots (@ and @home) before it does its work. Snapper will make four; two before and two after, because it has a "diff" command.
5. Do not enable mount -o discard, autodefrag, or space_cache=v2.
6. Overprovision your SSD and/or use TRIM to maximize factory built in overprovisioning. You "overprovision" by making your sda1 partition 25-50% less than the full size of your ssd, which already has about 7.3% built in factory overprovision. The unused raw partition will be used as free space by the ssd.
7. Periodically run btrfs defrag against source subvolumes, i.e., @ and @home, or you can use / and /home. They do NOT have to be unmounted.
8. Never run btrfs defrag against a child subvolume (eg: snapshots). This is an argument against Snapper and Timeshift, since they store their snapshots under / and /home, while the method I use stores them at the <ROOT_FS> level, reached by mounting sda1 to /mnt (which becomes <ROOT_FS>. Note: I don't use sda1 in the mount command, I use the uuid of sda1.
9. Insure that the number of snapshots per volume/filesystem never exceeds 12; two or three times that might not cause ill effects, but keeping it under this number provides the greatest odds for avoiding morbid performance issues and out of space conditions. On the upside, many more btrfs snapshots can be taken before performance crashes when compared to LVM snapshots, where a single snapshot can introduce a performance crash.
10. Take care to not fill the volume beyond 90%. The performance will become less predictable. Why? As you use your system and make changes those changes are added to your snapshots. IOW, they begin to populate. i.e., fill up. To begin with they were essentially empty! Only links and metadata. If you have a dozen of them filling up as your 110GB of data on your 750GB HD change due to additions, deletions, updates, etc., eventually your snapshots combined with your data will consume more than 90% of the space on your HD. When your system slows down you will know something is wrong. How many snapshots you can take depends on the total size the data in / and /home, and the total size of your HD. The most I've had on my <ROOT_FS> is about 16, but none of them became fully populated. IF you have a 1TB HD then 90% of that is 900GB. If your data is 100GB in total, then you can safely keep 8 fully populated snapshots. As things turned out, I usually make a snapshot of @ and @home before I do a massive update, or update my printer or display drivers, or experiment with an app or a technology like P2P. I usually keep 3 or 4 sets (6 to 8) of snapshots and delete the oldest pair to make room for the new set. All of them are made ro. After a massive update I'll send & receive that set to my 2nd or 3rd archival HD, or to my 320GB USB external HD. So, no snapshot stays around long enough to populate to my full 110GB of data. Ergo, I've never had a performance problem with my setup. What's the cure if you have problems? Use the Btrfs delete command to delete your oldest snapshots, leaving 3 or 4 sets, then run the scrub command to clean up the extents. Follow that with the defragment command, then use the btrfs usage command to see how much space you've recaptured. Run periodic balances and defrags to consolidate free space into contiguous chunks. Run TRIM in cron periodically to free up unused extents.
    
    I mentioned that I make all my snapshots "ro", i.e., read only. They are created by using the "-r" switch in the snapshot command. Read only snapshots differ from read write snapshots in one distinct way: the ro snapshot cannot be moved (mv) outside its parent subvolume. And the way to move a snapshot to another subvolume is to use the Btrfs send & receive commands, which require that the snapshot be ro. You can convert an ro snapshot to rw by using the snapshot command without the "-r" switch, or, you can use the property set command: "btrfs property -ts @ ro false" turns the read only @ snapshot to a read-write @ snapshot. Using "true" would reverse the setting. "-t" is type: s=subvolume, d=directory, f=file, i=inode.

Finally, if you want to save a snapshot to a destination that is not a Btrfs subvolume, i.e., EXT4 or NFS, then use the "-f" switch in the send & receive command. It will send the subvolume to the destination as a string of ASCII characters. Using send & receive will restore it as a subvolume on a Btrfs system. That's what the docs say, but I've never tried it myself. Something to experiment with!

[kc1di]

Than You GG for the tutorial it will come in very handy as I transition to Btrfs in the future.