> I never had the guts to try btrfs in production after all the horror stories I've heard over the decade+.
I've been running btrfs as the primary filesystem for all of my desktop machines since shortly after the on-disk format stabilized and the extX->btrfs in-place converter appeared [0], and for my home servers for the past ~five years. In the first few years after I started using it on my desktop machines, I had four or five "btrfs shit the bed and trashed some of my data" incidents. I've had zero issues in the past ~ten years.
At $DAYJOB we use btrfs as the filesystem for our CI workers and have been doing so for years. Its snapshot functionality makes creating the containers for CI jobs instantaneous, and we've had zero problems with it.
I can think of a few things that might separate me from the folks who report issues that they've had within the past five-or-ten years:
* I don't use ANY of the built-in btrfs RAID stuff.
* I deploy btrfs ON TOP of LVM2 LVs, rather than using its built-in volume management stuff. [1]
* I WAS going to say "I use ECC RAM", but one of my desktop machines does not and can never have ECC RAM, so this isn't likely a factor.
The BTRFS features I use at home are snapshotting (for coherent point-in-time backups), transparent compression, the built-in CoW features, and the built-in checksumming features.
At work, we use all of those except for compression, and don't use snapshots for backup but for container volume cloning.
[0] If memory serves, this was around the time when the OCZ Vertex LE was hot, hot shit.
[1] This has actually turned out to be a really cool decision, as it has permitted me to do low- or no- downtime disk replacement or repartitioning by moving live data off of local PVs and on to PVs attached via USB or via NBD.
>At $DAYJOB we use btrfs as the filesystem for our CI workers and have been doing so for years. Its snapshot functionality makes creating the containers for CI jobs instantaneous, and we've had zero problems with it.
I've been running btrfs as the primary filesystem for all of my desktop machines since shortly after the on-disk format stabilized and the extX->btrfs in-place converter appeared [0], and for my home servers for the past ~five years. In the first few years after I started using it on my desktop machines, I had four or five "btrfs shit the bed and trashed some of my data" incidents. I've had zero issues in the past ~ten years.
At $DAYJOB we use btrfs as the filesystem for our CI workers and have been doing so for years. Its snapshot functionality makes creating the containers for CI jobs instantaneous, and we've had zero problems with it.
I can think of a few things that might separate me from the folks who report issues that they've had within the past five-or-ten years:
* I don't use ANY of the built-in btrfs RAID stuff.
* I deploy btrfs ON TOP of LVM2 LVs, rather than using its built-in volume management stuff. [1]
* I WAS going to say "I use ECC RAM", but one of my desktop machines does not and can never have ECC RAM, so this isn't likely a factor.
The BTRFS features I use at home are snapshotting (for coherent point-in-time backups), transparent compression, the built-in CoW features, and the built-in checksumming features.
At work, we use all of those except for compression, and don't use snapshots for backup but for container volume cloning.
[0] If memory serves, this was around the time when the OCZ Vertex LE was hot, hot shit.
[1] This has actually turned out to be a really cool decision, as it has permitted me to do low- or no- downtime disk replacement or repartitioning by moving live data off of local PVs and on to PVs attached via USB or via NBD.