In a conversation at my local LUG, I learned that Fedora is now shipping with btrfs as it's default filesystem. I don't use Fedora, but it's an interesting development, nonetheless. Members were extolling it's greatness.

I got to reading about btrfs, and I have some immediate concerns. These concerns circle around the *nix idea that things should do one thing, and do that one thing well. But btrfs seems to be trying to encompass many things at the filesystem level; RAID, LVM, snapshots, compression, disk spanning, checksums ... and the list seems to go on. Most of these things have traditionally been handled separately.

Is this a recipe for disaster? Are they trying to do too much? Or is it a recipe for a great tasting cake?

Not really, it attempts to redefine and update some things and establish a more sensible concept of what a filesystem really is, while expanding limits and expanding upon the best features of pre-existing filesystems. It does integrate the features of some other packages, but only so it can do its ONE SINGLE JOB better and with less complexity. This is a kind of integration of features to simplify that we see often and does not violate the Unix philosophy as long as it does not include features not suitable for the primary function. (SYSTEMD is a FAR bigger concern in that sense!)

Better is an ill defined term. Better for what? It handles SSD storage better natively than the EXT2/3/4 family, but does not quite provide the same performance. It adds useful (and very powerful) features we really WANT to have that few other filesystems provide. RAID-0/1/10 features are native and secure and work without additional software, but RAID-5/6 are not yet ready for prime time (They work, but some conditions do not recover properly that can be handled by older software. They (we) are working on that.)

I am very comfortable with BTRFS in the most common case: single or multiple drive workstation without raid or with mirroring only. The snapshot and recovery features, if you need them, are like magic. The performance and security for use without raid or with only raid 1 or 0 are more than good enough. I would say it is very good.

That said I would rather use EXT4/MD RAID-6/LVM if I needed maximum performance data storage with drive failure protection in a commercial environment.

None of those cases remove the requirement for proper backups and backup/restore testing with offsite storage to provide data security against disaster or total environment failure. If you store no such data and do not mind reloading your platform (laptop?) every year or two, then you can skimp on the backups, otherwise cover your @$$.

2 members found this post helpful.

I'd look at phoronix web site for some test results. There are situations where that advanced filesystem would benefit the user. It is really much more than a filesystem.

ZFS has already done for years most of what BTRFS is just now becoming able to do sort of reliably. It is very disappointing that most filesystems not BTRFS/ZFS do not have checksums, redundancy in the event of hardware failure, on-the-fly compression, or the ability to send/recv incremental backups. Even Apple's new filesystem does not care about data integrity. There is nothing especially "enterprise" about wanting to check your data and to be able to easily back it up, yet Mac/Linux/Win have never provided easy, convenient ways to do these two simple things OOB.

1 members found this post helpful.

Funny, I always thought it stands for ButterFS. So my conclusion is:

1 members found this post helpful.

Slippery as butter. Or as melty under high heat.

My experience is that it's nice most of the time. Really makes no difference whether I'm using it or not, on my desktop I certainly can't tell the difference between using ext4+xfs (/ and /home) and btrfs (both).

Sometimes the supporting services can be CPU hogs and slow the system significantly - but this is relatively infrequent (although a great annoyance when it happens).

When it breaks, it breaks in a real bad way. I've gotten totally unrecoverable filesystems as a result of a hard reset.

1 members found this post helpful.

RAID - block device RAID does not know which mirror leg to pick when there is a mismatch. This could be solved if the linux read() syscall added an optional int "mirror leg" parameter so that file systems (or the integrity block device layer) with checksums could then try all the legs. But it hasn't, so filesystems level RAID is the only way to resolve mismatch. Plus, filesystem RAID has the option of mirroring only metadata.

LVM - btrfs doesn't replace LVM. I run btrfs on top of LVM. A "subvolume" is not a block device you can pass to KVM. Sure, you could make a giant file and use loopback driver - but an LVM volume is much more efficient.

shapshots - btrfs snapshots are very different from LVM snapshots, which are different than LVM "thin" snapshots. LVM classic snapshot is ideal for backups - but multiple snaps of the same volume quickly degrade in performance. Btrfs snaps proliferate without penalty even more than LVM "thin" snaps. BUT - dnf gets confused when checking disk space for an upgrade. Removing the old versions of files doesn't necessarily release any space if the blocks are also referenced in one or more snapshots.

compression - while there are compressing block device layers, they just don't have enough information to do it as well as a filesystem.

disk spanning - true, block layers like LVM can do this just as well. EXCEPT, you can remove any device, and btrfs will migrate the data to other devices. LVM can do this with a lot of careful manual sequencing (when the removed device is in the middle of a span), and filesystem shrinking. But btrfs does it automatically.

checksums - as noted above, block device checksum layers don't have the API to cooperate with block device RAID layers to heal mismatches. Plus, filesystem checksums verify filesystem structures (metadata), which block layers don't have enough info to do. (Note: XFS also checksums metadata but not data.) You really want filesystem checksums on at least metadata - even if you have a block device integrity layer.

Lastly, non-techie end users find LVM and block layers in general very daunting. The Fedora installer can give them a default install that doesn't require adjusting space between root and home volumes.

2 members found this post helpful.

Excellent post - after all these years ...

Two things that really sold brtfs for me:

Containers with nspawn, have a linux root on a brtfs subvolume and with overlay thats readonly but do snapshot(s) to save if you want. Start an nspawn container with "-x/--ephemeral". This blog post explains it better https://www.enricozini.org/blog/2021...-runner-btrfs/.

Fedoras default to split root and home on different subvolumes for logical separation but still dynamicly expand to use whole disk independent on what needs more space. It makes sense to me.