4 ms·

I've done many bad things to BTRFS, used it on multiple drives of differing sises, used it on drives connected over the cheapest USB to SATA adapters I could fi

by RX14 9y ago

I've done many bad things to BTRFS, used it on multiple drives of differing sises, used it on drives connected over the cheapest USB to SATA adapters I could find, used it on disks with consistent corruption for over a year, and it's handled it gracefully. I've also been using btrfs as the backend to docker for a long time on my desktop PC and never noticed any problems. BTRFS has been rock solid for me. I don't doubt it is more unstable than other filesystems, however it seems i haven't been unlucky enough to experience any issues. When using BTRFS, i've always stuck to the latest kernel releases, and run a scrub + balance every month. This is the advice I heard from people who used btrfs, and I wonder how many of the people who complain about data corruption do these steps. Perhaps their corruption bugs are solved in a newer kernel version. I've had multiple scrubs pick up data corruption, which other filesystems wouldn't have found. The only time btrfs corrupted my data was when I used the ext4 to btrfs conversion tool, it created an unmountable FS and then I just migrated my data manually.

rleigh 9y ago
You shouldn't have to do these steps. Manual balancing is a workaround for a critical flaw in the implementation. In my last major use of Btrfs, whole archive rebuilds of Debian, it would take less than 48 hours to completely unbalance a brand new Btrfs filesystem. ~25k snapshots continuously created and deleted over the period in 20 parallel jobs absolutely toasted the filesystem, even though it was 1% utilised for the most part, 10% at peak usage. The point I want to make is that a Btrfs filesystem can become unbalanced at some indeterminate point in the future, which makes it impossible to rely on if you want to guarantee continued service. I've also suffered from a number of dataloss incidents which likely are fixed now, but despite lots of bugfixing, there are still major flaws to address.
cookiecaper 9y ago
btrfs requires far too much maintenance to be a good general-purpose FS, and it absolutely crumbles under certain not-too-uncommon use cases (specifically, databases and VMs). I really wanted to like btrfs and used it extensively over the last couple of years, but I've finally given up and moved on to ZFS, and I'm grateful that I did. Give it a try.

by RX14 9y ago

rleigh 9y ago

You shouldn't have to do these steps. Manual balancing is a workaround for a critical flaw in the implementation. In my last major use of Btrfs, whole archive rebuilds of Debian, it would take less than 48 hours to completely unbalance a brand new Btrfs filesystem. ~25k snapshots continuously created and deleted over the period in 20 parallel jobs absolutely toasted the filesystem, even though it was 1% utilised for the most part, 10% at peak usage. The point I want to make is that a Btrfs filesystem can become unbalanced at some indeterminate point in the future, which makes it impossible to rely on if you want to guarantee continued service. I've also suffered from a number of dataloss incidents which likely are fixed now, but despite lots of bugfixing, there are still major flaws to address.

cookiecaper 9y ago

btrfs requires far too much maintenance to be a good general-purpose FS, and it absolutely crumbles under certain not-too-uncommon use cases (specifically, databases and VMs). I really wanted to like btrfs and used it extensively over the last couple of years, but I've finally given up and moved on to ZFS, and I'm grateful that I did. Give it a try.