Do I need to run a balance regularly?
In general usage, no. A full unfiltered balance typically takes a long time, and will rewrite huge amounts of data unnecessarily. You may wish to run a balance on metadata only (see Balance_Filters) if you find you have very large amounts of metadata space allocated but unused, but this should be a last resort. At some point, this kind of clean-up will be made an automatic background process.
Yes in theory that is the best practice, but a big assumtion there is that BTRFS is run less than 85% capacity.
Balancing
A Btrfs balance operation rewrites things at the level of chunks. It runs through all chunks on the filesystem, and writes them out again, discarding and freeing up the original chunks when the new copies have been written. This has the effect that if data is missing a replication copy (e.g. from a missing/dead disk), new replicas are created. The balance operation also has the effect of re-running the allocation process for all of the data on the filesystem, thus more effectively ābalancingā the data allocation over the underlying disk storage.
All filesystems for best performance should have some minimum percentage of free space, usally 5-10%. Btrfs, using a two-level space manager (chunks and blocks within chunks) plus being based on (nearly) copy-on-write, benefits from more space to be kept free, around 10-15%, and in particular from having at least one or a few chunks fully unallocated.
It is quite useful to balance periodically any Btrfs volume subject to updates, to prevent the allocation of every chunk in the volume. Usually it is enough to balance periodically only the chunks that are just 50% used or 70% used and this is quick, for example as:
But that goes out the window when the disk gets above 85% full.
Then you find out (rather suddenly) that although your disk isnāt theoretically full (there is space in used blocks), there are no longer any un-allocated blocks and you hit a problem.
As Fedora 33 have switched to btrfs and openSUSE use it for years, it really make sense for Ubuntu to not stick out. But I could imagine that the plan is to switch to ZFS instead
I currently run Ubuntu MATE 20.04.2LTS with 5.10.15 kernel from ubuntu mainline kernel with ZFS 2.0.3 from PPA. The problem with ZFS root is that sometimes the latest kernel doesnāt compile against the ZFS package installed for whatever reason. For example, the latest 5.10.16 doesnāt, while 5.10.15 does. It is sporadic. When ZFS doesnāt support a latest kernel series, and you try to upgrade kernel, you get an unbootable ZFS root and you are stuck at a grub screen. And this has been the biggest issue for ZFS root for the foreseeable future, because of licensing issues. It is certainly not suitable for Ubuntu server use also because of it. You donāt want a probability of a unbootable server after kernel upgrade.
So I think moving to BTRFS root default both for Ubuntu desktop and Ubuntu server is a decent choice. While I still want to use ZFS for data partitions because the zpool of arbitraging multiple storage mediums(zil,l2arc,and HDDs) is superb.
In the end, I support BTRFS mirrored root for both Ubuntu Server/Desktop. Unless Ubuntu is aimed at ZFS root, which is a technically superior solution compared to BTRFS, then Ubuntu should provide a first-party PPA repository for kernels compiled with ZFS built in, not the dkms stuff. Either way, for data, I will still choose to use ZFS over BTRFS. Both file systems now support ZSTD compression, which is good, and should be default also.
Iām using OpenSUSE Tumbleweed, which comes with BTRFS by default, and snapshots filled up my SSD. No problem, you just need to delete old snapshots and you are back in business.
I think this discussion should be revived, at least provide the option to easily specify BTRFS at install time both on the desktop and server.
Personally, I am very happy with the performanceā¦ especially considering 3 of the last 4 kernel releases had performance patches for BTRFSā¦ and any loss in performance would be more than made up for by virtual of having patch rollback and snapshots.
If not default Ubuntu should At-least give a Option to Switch to BTRFS easily without manual intervention, currently manual setup of BTRFS with ubuntu subvolume style is a bit difficult and error-prone, so ubuntu instead of zfs should give btrfs as a second option for the edge users atleast, Ubuntu is known as the futuristic distro in trhe categories of Debian Based DEs and as such this step will be visionary and in line with Vision Of Ubuntu
Unfortunately for those who manually choose BTRFS during the installation, with the new Installer introduced on Ubuntu 23.04 we have a regression on the support for BTRFS: no support for the subvolumes.
To date, for those who want to install Ubuntu with Btrfs it is advisable to avoid the ISO with the new Installer (I hope it is correct in the next versions).
Report bugs: https://bugs.launchpad.net/subiquity/+bug/1881932
Yes, it should be a checkboxā¦ I have a cloudinit script for my servers that creates servers with everything broken down into subvolumes so I can roll back OS patches without having to roll back data etcā¦ itās been very useful, but itās a bit of a faf to re-organise everything during the packer buildā¦ I did write a hook that takes a snapshot of the os whenever dpkg is called by aptā¦ however to make this viable I had to move the dpkg/apt data onto the root subvolume as otherwise the package database would get out of sync whenever you rolled back / without also rolling back /var.
I found a great āguideā for an Ubuntu 22.04 (in my case) BTRFS installation that included info on installing and setting up āgrub-btrfsā, Timeshift (BTRFS snapshot & restore etc) and Timeshift Auto-Snap (takes a snapshot any time āaptā is used to install/remove/delete something).
