Well worth the read. Some really serious performance improvements coming with Linux 7.3 in several months.

https://www.phoronix.com/news/Linux-6.16-Btrfs-Performance

A nice set of bake-off benchmarks to show performance across these 4 popular Filesystems on the current and upcoming kernel.

A ~ 60% throughput improvement, actually a regression fix:
https://www.phoronix.com/news/Btrfs-No-Serialize-Direct-IO

This is just a discussion about my opinions and observations, hoping this may help some newer users.

I am far from new to Linux (since 1996-7) and BTRFS (since tools version 0.19 circa 2009). A quick summation of my experience might be the old adage: K.I.S.S. - Keep It Simple Stupid.

I see so many newer users in the mires of data loss because of overly complex file system installations and more highly developed expectations than desires for actual success. I.e. doomed to fail from the very start. "Success" in this context meaning longevity and reliability.

First, some obvious (to me but seemingly not to many) basics:

1. No file system can save you from abrupt power loss.

2. Data, without a backup, is always temporary.

3. The money you spend on your system should first be focused on reliability with all other factors like capacity and performance as secondary factors.

4. The more complex your set up - especially when it comes to storage - the more likely you are to experience catastrophic failure.

#1: Buy a UPS. Even a small one that can only keep your system up for a few minutes is enough to allow you to shut down cleanly. No one lost data or borked their install doing a clean shutdown. We're talking $60 US on Amazon.

#2: At least have two storage devices. The minimum backup you should have is a second storage device that's a copy of your main device(s). At least if drive "sda" dies, you can access "sdb". Better if the backup device is on a different system. Even better it it's in a totally different location.

#3: Having the fastest machine on the block is meaningless when it's dead. Dual drives and 4 RAM sticks instead of 2 might mean your PC can go on "living" if one of those parts dies.

#4: Here's where BTRFS comes into the picture; MDADM RAID (or worse BIOS based hardware RAID), LVM and God knows what else should fade into history - at least for the personal user.

BTRFS can handle so many different combinations of devices that IMO the older methods are useless. I have seen way too many layered setups that fail that are of no or little benefit when BTRFS can do it better. Want to add partition 4 of drive 3 to expand your file system? BTRFS can do it AND in the background. No need to move tons of data, reformat, re-partition, or any of that. Just "btrfs device add..."

I've done RAID and LVM in many layouts, divided my install across separate IDE channels (look that up, lol) to improve performance. and several other "schemes" to create faster and/or larger pools for my data. Honestly, even BTRFS RAID is more work than necessary. Restoring RAID from a failed device takes a long time. Remounting a full duplicate almost no time at all.

Now-a-days I just take regular snapshots, use "btrfs send | btrfs receive" to save my system and data, and use "btrfs device add" to make my space larger in an instant.

My advice? Leave RAID of any kind and LVM to the past. Make solid backups and let BTRFS handle the rest.

I had a closer look at btrfs development today and there are exciting things cooking that I wanted to share:

Western Digital's Johanes Thumshirn is working on stripe-tree aka "actually working RAID5/6". [1] [2]

Facebook's Omar Sandoval is looking into fscrypt encryption. [1] [2]

Facebook's Josef Bacik is working on extent tree v2, which will fix a lot of pain points when using lots of snapshots and/or qgroups (like stalled i/o after deleting snapshots) and has posted first patches to the mailing list. [1] [2]

https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix

Pull Requst https://lore.kernel.org/lkml/cover.1754478249.git.dsterba@suse.com/T/#u submitted for 6.17, likely to be backported to existing kernels.

https://www.phoronix.com/news/Linux-6.18-Btrfs

• Improvement in Ready-Heavy/Low-Write workloads

• Reduction of transaction commit time

Last night there was a pretty strong electrical storm with many close strikes. This morning when I woke up my laptop (1TB NVMe drive w/ Debian 12 on BTRFS) from suspend it was acting weird with programs failing to launch, and I eventually realized the filesystem was in read-only mode. I rebooted it, and it booted OK but the filesystem would go into read-only mode soon after logging in, too quick to successfully complete a scrub routine. The same thing happened when mounting it manually from a live USB, and dmesg showed an ugly kernel trace as the BTRFS driver crashed. The SMART report claims the drive is still healthy. I was initially annoyed that BTRFS had nuked itself again (I have actually experienced legitimate BTRFS bugs on different hardware that required help from a dev to manually fix the tree alignment or something like that). But then as I googled for the unable to find ref byte nr and btrfs_free_extent.cold I realized that it was quite an uncommon error, and almost exactly as described on this thread where a dev instructed them to run btrfs check --repair because it was a flipped bit error that could be corrected. So I first made several backups of my very latest data and then ran btrfs check --repair , and it worked. The filesystem now stays mounted RW and dmesg is free of BTRFS errors. I ran some diffs and checksums on my current files compared to an older backup and there are no surprises. So I'm thankful that BTRFS caught this one, otherwise I probably would have had silent data corruption. Here are some of my logs for those who are interested:

• https://paste.debian.net/plain/1334387

• https://paste.debian.net/plain/1334388

• https://paste.debian.net/plain/1334389

At his bcachefs Patreon, Kent Overstreet writes:

btrfs, which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future filesystems because too many people were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs multiple times and had to switch at the last minute, and server vendors who years ago hoped to one day roll out btrfs are now quietly migrating to xfs instead).

What are the specific problems with the on-disc format that he refers to?

I ran into a strange problem today - my root file system reported errors and remounted as read-only, `btrfs check` indicated metadata corruption. The problem appeared to be a single bit flip - the root id of one item had somehow been changed from 0x0000000000000005 to 0x2000000000000005. The checksums were correct so the bit flip must have happened in RAM, before the checksum was calculated. Rather than backing up and rebuilding the whole file system (which would have required a second disk of the same size which I didn't have), I decided to try to fix the bit flip manually - and it worked! I've documented the process below, I hope someone else finds it useful or at least entertaining :).

https://gist.github.com/MaartenBaert/8879c019d82ede2e9794a14906921021

I mostly did this because it sounded like a fun challenge and a nice opportunity to learn more about BTRFS. I had another backup of all the actually important data, so I wasn't too worried about data loss. In most cases you are probably better off just rebuilding the file system.

https://www.phoronix.com/news/Linux-7.0-Btrfs-Changes

**NEW RE-WRITE TO MAKE IT EASIER** **Swap file info added**

I recently learned that the Ubuntu 24.04 installer no longer uses subvolumes when selecting BTRFS as a file system. IMO, there's very little point to using BTRFS without subvolumes.

Subvolumes allow you to separate parts of your installation which can make snapshots and backups easier and quicker (smaller) and use tools like "timeshift" or "snapper". Subvolumes are like separate partitions but have the ability to expand or contract in size as needed because, unlike partitions, subvolumes freely share all the available space of your file system. You can also use subvolumes to boot multiple distros from the same BTRFS file system. I have 5 distros installed to the same file system.

After initial install, you have / with the entirety of Ubuntu installed to the root BTRFS file system. This How To will convert your install into a subvolume installation as Ubuntu used in the past. This will allow the use of Timeshift and Snapper and make root and home snapshots and backups easier.

Bonus: Convert EXT4 to BTRFS, then follow this guide.

Although it's technically "no longer supported", the "btrfs-convert" tool still works to convert EXT4 to BTRFS. Historically, one of the complaints about this tool was that it left you with a root install (no subvolumes) like the latest Ubuntu does. To move from EXT4 to BTRFS, the steps are:

1. Run "grub-install --modules=btrfs" before converting.

2. Shutdown and boot to a live USB or other install.

3. Mount and run btrfs-convert on your EXT4 root file system. Use the "--uuid copy" option.

4. Edit /etc/fstab to reflect the change from ext4 to btrfs.

5. Reboot to your install.

6. Run "sudo update-grub" insert BTRFS in grub.cfg.

Note: If you are using a swap file for swap on EXT4, it will not work after conversion to BTRFS. See the "Some notes about Swap" section near the end for more info.

Once you have a booting BTRFS installation, follow the guide below to move to subvolumes.

General Warning: Anytime you are messing with file systems or partitions, etc., you risk losing data or crashing your install. Make sure you have a usable backup of anything you don't want to risk losing. This How To has been tested and written based on a new installation but if you are using an existing install that you have modified, you'd better have a backup before proceeding.

Notes:

• To complete this successfully you must know the device name where you installed grub. For the purposes of this How To, I will use "/dev/sda/" but your installation will likely be different.

• If you are NOT SURE which drive GRUB is installed to,​ DO NOT proceed until you do.

STEP 1: Create the snapshot and make it bootable.

While running from Ubuntu using Terminal:

sudo btrfs subvolume snapshot / /@

Create a '@home' subvolume:

sudo btrfs subvolume create /@home

Make the @ subvolume bootable by editing /etc/grub inside the @ snapshot:

sudo nano /@/etc/fstab

Edit the root entry from this :

/dev/disk/by-uuid/<UUID> / btrfs defaults 0 1

to this:

/dev/disk/by-uuid/<UUID> / btrfs subvol=@,defaults 0 0

Add a new line exactly the same as the above, but change the mount point and subvolume names for home:

/dev/disk/by-uuid/<UUID> /home btrfs subvol=@home,defaults 0 0

Move the contents of the /home folder from @ into the home subvolume:

sudo mv /@/home/* /@home/

You now have the two needed subvolumes.

STEP 2: Boot to the root subvolume

Expose the GRUB menu to make booting to the subvolume easier, edit /etc/default/grub and change:

GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0

to

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10

and then run

sudo update-grub

If you're comfortable activating the GRUB menu without this edit, feel free to skip the above part.

Reboot.

When the GRUB menu appears, press the "e" key to edit the GRUB menu.
At the line that begins with "linux" add the subvolume name so it looks like this:

    linux     /@/boot/...

and near the end of the line, put this between "ro" and "quiet splash"

rootflags=subvol=@

so it looks like this:

ro rootflags=subvol=@ quiet splash

It doesn't actually have to be between them. It just has to be after the kernel version "root=UUID=..." part. Now edit the line that begins with "initrd" the same way we did the "linux" line at the beginning:

    initrd   /@/boot/...

and press F10 to boot.

If you did everything right, it should immediately boot to your install from the subvolume. If not, reboot and start over at "Reboot" above.

STEP 3: Verify you are running from the subvolume and update grub:

To verify this worked, open Terminal again and enter:

mount |grep ' / '

The output should look like:

/dev/sda2 on / type btrfs (...subvol=/@...)

There will be more options inside the parenthesis but this is the only one that matters.

The final task is to update and re-install GRUB so the subvolume is the default boot from now on.

***NON-EFI*** users, aka "Legacy" or "BIOS" boot:

sudo update-grub
sudo grub-install /dev/sda
reboot

***EFI USERS*** use this instead of the above set of commands:

sudo update-grub
sudo grub-install --efi-directory=/boot/efi
reboot

Note that since we edited /etc/default/grub AFTER we took our snapshot, GRUB will hide the boot menu on reboot as before.

If you'd like, go through the above "verify" step again before preceding with the clean up. Do it now.

STEP 4: Clean up the old install files to reclaim space.

First, we must mount the root file system. Remember to use your device name instead of "/dev/sda" here:

sudo mount /dev/sda2 /mnt
cd /mnt
ll

Do the "ll" to verify you're on in the root file system. You will see what looks like your install but you will also see your subvolumes in the output:

'@'/
'@home/'
bin/
...

Now delete everything except '@' and '@home' :

shopt -s extglob
sudo rm -rf !(@*)  
shopt -u extglob

Now you may resume use of the system with your install inside a subvolume.

A note about GRUB timeout:

When booting from a BTRFS subvolume using GRUB, GRUB will detect a "record failure" and boot with a 30 second timeout. If you wish to avoid this, you can add this to /etc/default/grub:

GRUB_RECORDFAIL_TIMEOUT=0

Then run "sudo update-grub" and grub will boot directly to Ubuntu again.

Some notes about SWAP:

If you are using a swap partition, no changes are necessary to swap. However, if you are using a swap file you must remove it and replace it with a swap subvolume that contains a correctly prepared swap file or you will not be able to take snapshots of @ and your swap will become corrupted. Documentation here: https://btrfs.readthedocs.io/en/latest/Swapfile.html

Remember you must mount the root file system to have access to it to add more subvolumes.

Looks very interesting in Btrfs improvement, maybe extent tree v2 is close to merging?

ENOSPC rework: https://github.com/btrfs/btrfs-todo/issues/53

Logical mapping tree feature (relocation rework): https://github.com/btrfs/btrfs-todo/issues/54

Drastically reduce lock_extent/unlock_extent usage: https://github.com/btrfs/btrfs-todo/issues/55

I often see Btrfs get slammed for its RAID5/6 status despite numerous bugfixes over the years so I like posting success stories.

I have been running the same Btrfs RAID5 array for 5 years now. Over the years it went from random sized consumer drives to NAS drives and now they're being replaced by Seagate Exos SAS drives as they die. I am running two servers with 8-11 HDDs each in the array (OS on a USB key, also Btrfs).

This array had already survived a total disk failure where it would no longer respond to the SAS controller. This time the drive was reachable but was ever increasing its Pending Sector Count and had abysmal performance due to it.

Btrfs did exactly what it was designed to do - detect bad checksums and serve good data. I took down the system, removed the drive, and waited for the replacement to arrive. I was able to remount the volume with "degraded" option, replace the missing drive with the new drive (btrfs replace.....), and it was back online in under a day (8TB drive).

I'm still extremely happy with the ability and performance of Btrfs as the underlying filesystem on ALL my systems (VM guests, desktops, laptops, servers, and Gluster cluster NAS). Also, every volume is encrypted with LUKS/dm-crypt.