Greetings, everyone. I have switched all my machines to use Bazzite. It has been one of the best decisions I have ever made, as I had distro-hopped for a while prior and just didn’t seem to be satisfied—until now.
Since Fedora atomic desktops use BTRFS by default, I have embraced it as a file system, regardless of some of the negative press it has received. I am using BTRFS RAID 1 and 0 volumes, each RAID level suiting a specific purpose. One thing I found out is that Bazzite doesn’t enable BTRFS maintenance tasks by default, and those who want to automate the process will have to create a systemd service.
I have been following the great information provided by this post but am running into a few issues. The command (btrfs scrub start -Bd /) to invoke a scrub on root doesn’t work. I end up receiving the following error: ERROR: not a btrfs filesystem: /. It looks like the root mount is based on composefs, an overlay filesystem. I am able to run scrubs on R/W BTRFS volumes such as /var and /var/home but not R/O, which prevents doing a scrub on /sysroot. However, if I change the scrub option to include the read-only flag (btrfs scrub start -Bdr /sysroot), it works.
What I’m trying to figure out is how to maintain BTRFS volumes properly on Bazzite. I can definitely automate scrubs, but how do I scrub all BTRFS volumes effectively, regardless of being R/O or R/W? I suppose I could use the read-only flag for the R/O volume to see if there are any errors. Then boot into a live environment, mount the disks, and then run a scrub to fix any that were previously reported.
I’m really looking for a best practice around this as it pertains to immutable distros based on RPM-ostree, in this case Fedora atomic like Silverblue, Kinoite, and the Universal Blue family. If anyone has looked into this already and could share your thoughts, I’d greatly appreciate it.
I am sincerely grateful to the Universal Blue community and everyone who takes time out of their day to contribute to this project. Cheers.
Because Bazzite is Atomic and image-based this is still less of a concern. I do not believe this to be a short to mid-term issue for general use
(unless of course you have stringent professional needs in which case having ECC memory and server grade SSDs would be starting points lol.)
…maybe after 4-5 years something like this comes into play…unless you have some very high write/rewrite cycles going on a regular basis…or you know the drives you are using are at increased risk of data corruption for various reasons.
For non-OS disk maintenance one can use the gnome disks utility that is included on Bazzite.
If I am not mistaken write cache on disks is off by default…which should reduce the risk of data corruption in the event of power failure (Example: turning computer off computer with power button while still in OS). It includes S.M.A.R.T. testing (depending on your disk) on by default for automatic checks at set intervals with data read outs. Additionally, you can check the filesystem for errors and repair it as well.
I would refer to documentation carefully and make any necessary backups before initiating any repairs though.
While I have no real complaints with the updates process to date…I would still be more concerned with updates breaking things over the risk of disk errors. In this regard I personally prefer using the manual “system update” option on a weekly basis over waiting for background updates to occur for various reasons.
Sorry, I’m going to bump my post to add links to some of the official BTRFS Documentation pages that are relevant for a bit more background…note that these links relate to the “latest” BTRFS release…the docs may vary from the “stable” release.
Some of these maintenance functions may carry a certain degree of data risk and may need greater expertise in BTRFS. Really, this stuff is probably best handled upstream by Fedora, KDE, and Gnome at the present moment.
I ended up settling on a script rather than a systemd service to perform BTRFS maintenance. Here’s an example for anyone interested:
#!/bin/sh
# some helpers and error handling:
info() { printf “\n%s %s\n\n” “$( date )” “$*” >&2; }
trap ‘echo $( date ) BTRFS maintenance tasks interrupted >&2; exit 2’ INT TERM
info “Starting BTRFS maintenance tasks”
# run scrub in read-only mode to identify issues on R/O volume
/usr/bin/btrfs scrub start -Bdr /sysroot
# run scrub in read-write mode to ensure fixes are applied if necessary
/usr/bin/btrfs scrub start -Bd /root
/usr/bin/btrfs scrub start -Bd /var/mnt/extra
# defragment only volumes backed by spinning disks
/usr/bin/btrfs filesystem defragment -r /var/mnt/extra
btrfs_maintenance_exit=$?
if [ ${btrfs_maintenance_exit} -eq 0 ]; then
info “BTRFS maintenance tasks finished successfully”
elif [ ${btrfs_maintenance_exit} -eq 1 ]; then
info “BTRFS maintenance tasks finished with warnings”
else
info “BTRFS maintenance tasks finished with errors”
fi
printf "%s " “Press enter to continue”
read ans
exit ${btrfs_maintenance_exit}
I’m sure those with more BTRFS knowledge pertaining to an atomic Fedora distro could chime in here on whether all bases are covered. This script doesn’t do anything with balancing, does a scrub on the R/O volume in read-only mode, and does a regular scrub on the R/W volumes. It only defragments volumes backed by spinning disks, as doing that on an SSD wouldn’t be wise.
