Changelog v1.17.4

[cdhowie]

Even a bitflip in RAM or on disk, which are not terribly uncommon issues. (Incidentally, this is why many people think btrfs is still unreliable, as it seemingly-randomly reports I/O errors in non-redundant configurations. In most cases it’s actually detected failed hardware where non-checksumming filesystems like ext4 would just truck ahead and give the application bad data. Both are hardware failures, but btrfs loudly reports the error.)

[Toyoo]

The biggest problems for me in btrfs are not some random bitflips. I store ~10TB of data, regularly scrubbing it and seeing exactly zero repairs.

The problems are large number of snapshots slowing down the file system considerably, consistently bad performance of random-write files, such as VM disk images, the fact that when you defrag files (like said VM disk images) to fix performance issues, the FS disassociates snapshot copies, and the worst—bad free space accounting. I’ve had a case where by just running some combination of balancing and defrags I “freed up” 10% of diskspace.

This file system unfortunately still has a long way to go.

[cdhowie]

Thankfully I don’t need a large number of snapshots, nor do I use btrfs to hold VM disk images. I give my VMs direct access to LVM logical volumes and have the VM run btrfs on top of those. I also run with zstd compression and bees for deduplication.

It has “a long way to go” for some use cases, but there’s plenty of cases where it’s a perfect fit.

[kevink]

maybe you should try zfs then. I’d say it’s better than btrfs.

[Pentium100]

I like zfs it works rather well with VMs too.

[Toyoo]

I can’t invest in same-sized drives upfront.

[kalloritis]

That is kinda the rub of ZFS- generally your drives within a VDEV are all the same size and generally you make each VDEV the same composition of the others of that pool.