Btrfs—quick for “B-Tree File System” and regularly pronounced “butter” or “butter eff ess”—is essentially the most superior filesystem current within the mainline Linux kernel. In some methods, btrfs merely seeks to supplant ext4, the default filesystem for many Linux distributions. However btrfs additionally goals to supply next-gen options that break the straightforward “filesystem” mould, combining the performance of a RAID array supervisor, a quantity supervisor, and extra.
We’ve excellent news and dangerous information about this. First, btrfs is a wonderfully cromulent single-disk ext4 substitute. However in the event you’re hoping to exchange ZFS—or a extra complicated stack constructed on discrete RAID administration, quantity administration, and easy filesystem—the image is not fairly so rosy. Though the btrfs venture has mounted lots of the obtrusive issues it launched with in 2009, different issues stay primarily unchanged 12 years later.
Chris Mason is the founding developer of btrfs, which he started engaged on in 2007 whereas working at Oracle. This leads many individuals to imagine that btrfs is an Oracle venture—it isn’t. The venture belonged to Mason, to not his employer, and it stays a neighborhood venture unencumbered by company possession to this present day. In 2009, btrfs 1.0 was accepted into the mainline Linux kernel 2.6.29.
Though btrfs entered mainline in 2009, it wasn’t truly production-ready. For the following 4 years, making a btrfs filesystem would show the next intentionally scary message to the admin who dared
btrfs, and it required a non-default
Y to proceed:
Btrfs is a brand new filesystem with extents, writable snapshotting, help for a number of gadgets and lots of extra options. Btrfs is very experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You must say N right here until you have an interest in testing Btrfs with non-critical knowledge.
Linux customers being Linux customers, many selected to disregard this warning—and, unsurprisingly, many misplaced knowledge in consequence. This four-year-long extensive beta might have had an enduring impression on the btrfs dev neighborhood, who in my expertise tended to fall again on “nicely, it is all beta anyway” each time user-reported issues cropped up. This was occurring nicely after
mkfs.btrfs misplaced its scare dialog in late 2013.
It has now been almost eight years because the “experimental” tag was eliminated, however lots of btrfs’ age-old issues stay unaddressed and successfully unchanged. So, we’ll repeat this as soon as extra: as a single-disk filesystem, btrfs has been steady and for essentially the most half performant for years. However the deeper you get into the brand new options btrfs gives, the shakier the bottom you stroll on—that is what we’re specializing in at present.
Btrfs solely has one true competitor within the Linux and BSD filesystem area: OpenZFS. It is nearly not possible to keep away from evaluating and contrasting btrfs to OpenZFS, because the Venn diagram of their respective characteristic units is little greater than a single, barely lumpy circle. However we will attempt to keep away from immediately evaluating and contrasting the 2 as a lot as attainable. In case you’re an OpenZFS admin, you already know; and in the event you’re not an OpenZFS admin, they’re not likely useful.
Along with being a easy single-disk filesystem, btrfs gives a number of disk topologies (RAID), quantity managed storage (cf., Linux Logical Quantity Supervisor), atomic copy-on-write snapshots, asynchronous incremental replication, computerized corrupt knowledge therapeutic, and on-disk compression.
Comparability with legacy storage
In case you wished to construct a btrfs- and ZFS-free system with comparable options, you’d want a stack of discrete layers—mdraid on the backside for RAID, LVM subsequent for snapshots, after which a filesystem resembling ext4 or xfs on the highest of your storage sundae.
An mdraid+LVM+ext4 storage stack nonetheless finally ends up lacking a few of btrfs’ most theoretically compelling options, sadly. LVM gives atomic snapshots however no direct snapshot replication. Neither ext4 nor xfs gives inline compression. And though mdraid can provide knowledge therapeutic in the event you allow the
dm-integrity goal, it kinda sucks.
dm-integrity goal defaults to a particularly weak
crc32 hash algorithm vulnerable to collisions, it requires utterly overwriting goal gadgets on initialization, and it additionally requires totally rewriting each block of a changed disk after a failure—above and past the complete drive-write essential throughout initialization.
In brief, you actually cannot replicate btrfs’ complete promised characteristic set on a legacy storage stack. To get the entire bundle, you want both btrfs or ZFS.
Btrfs multiple-disk topologies
Now that we have lined the place issues go incorrect with a legacy storage stack, it is time to check out the place btrfs itself falls down. For that, the primary place we’ll look is in btrfs’ a number of disk topologies.
Btrfs gives 5 a number of disk topologies:
btrfs-raid6. Though the documentation tends to refer to those topologies extra merely—eg., simply as
raid1 reasonably than
btrfs-raid1—we strongly advocate retaining the prefix in thoughts. These topologies can in some circumstances be extraordinarily completely different from their standard counterparts.
|Topology||Typical model||Btrfs model|
|RAID0||Easy stripe—lose any disk, lose the array||Easy stripe—lose any disk, lose the array|
|RAID1||Easy mirror—all knowledge blocks on disk n and disk o are equivalent||Assured redundancy—copies of all blocks might be saved on two separate gadgets|
|RAID10||Striped mirror units—eg., a stripe throughout three mirrored disk pairs||Striped mirror units—eg., a stripe throughout three mirrored disk pairs|
|RAID5||Diagonal parity RAID—single parity (one parity block per stripe), mounted stripe width||Diagonal parity RAID—single parity (one parity block per stripe) with variable stripe width|
|RAID6||Diagonal parity RAID—double parity (two parity blocks per stripe), mounted stripe width||Diagonal parity RAID—double parity (two parity blocks per stripe) with variable stripe width|
As you may see within the chart above,
btrfs-raid1 differed fairly drastically from its standard analogue. To grasp how, let’s take into consideration a hypothetical assortment of “mutt” drives of mismatched sizes. If we have now one 8T disk, three 4T disks, and a 2T disk, it is troublesome to make a helpful standard RAID array from them—for instance, a RAID5 or RAID6 would want to deal with all of them as 2T disks (producing solely 8T uncooked storage earlier than parity).
btrfs-raid1 gives a really attention-grabbing premise. Because it would not truly marry disks collectively in pairs, it could possibly use the whole assortment of disks with out waste. Any time a block is written to the
btrfs-raid1, it is written identically to 2 separate disks—any two separate disks. Since there aren’t any mounted pairings,
btrfs-raid1 is free to easily fill all of the disks on the similar tough price proportional to their free capability.
btrfs-raid6 topologies are considerably much like
btrfs-raid1 in that—in contrast to their standard counterparts—they’re able to dealing with mismatched drive sizes by dynamically altering stripe width as smaller drives refill. Neither
btrfs-raid6 needs to be utilized in manufacturing, nevertheless, for causes we’ll go into shortly.
btrfs-raid0 topologies are a lot nearer to their standard counterparts, and for many functions these might be regarded as direct replacements that share the identical strengths and weaknesses.