After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.
I'm not sure what causes it, but there seems to be an effect where btrfs loves you or hates you and few people with mixed experiences regarding data loss. One possible cause is distro choice tends to be per person and how up to date said distro keeps it's kernel. But, I'm not sure.
Some of these are fixed by now, though.
I used to read every email on btrfs-devel for a year or so.
Basically, any time a runaway process filled my disk, I just had to hard-reboot and hope I didn't have any unsaved work or state that I needed to preserve.
Really makes me hope that Apple is going to further extend APFS to not just be baby's first CoW volume-management filesystem.
Do you have Time Machine enabled? I think it uses snapshots, which explains why the filesystem stays full. I've hit this myself and was initially surprised to see rm not improving matters (possibly even making it worse) but it makes sense with snapshots. The working on reboot was a surprise. I'd put off fixing the machine for at least a week, and when I went to actually fix it, it was quite anticlimatic to just reboot and have it work. Maybe it checks for this condition on reboot and dumps Time Machine snapshots if so.
That was the less scary part of my macOS filesystem integrity worries. My full disk started when it was staging a full Time Machine backup after I got a dialog saying:
> Time Machine completed a verification of your backups on "my.nas.address". To improve reliability, Time Machine must create a new backup for you.
...for the Nth time. I don't know for certain if the problem is with Apple's software or with my NAS's (Synology) but these backups are clearly not as reliable as one would hope...
If things still get trashed then I tend to think that the very foundation of the FS is bad.
But maybe I'm just naive :)
As with all his talks, you can expect it to be quite entertaining as well as informative and historical (if from his POV).
This is how superstitious traditions start, and ritualistic sacrifice in particular, I'd think.
Does data loss count as a sacrifice in this instance?
I wouldn't buy a $5 USB thumb drive if half the people said it lost their data and half said it worked fine.
of course, where we run into problems is that btrfs is meant to be the reliable backup. Oops.
I tried, I really tried to like btrfs.
On the servers/workstations I’ve had few serious issues, but a few “gotchas” you need to know to keep things running smoothly.
On every laptop I’ve had, I’ve had btrfs fail on me. Repeatedly.
So I gave up on it. ZFS for me these days.
The only difference is that none of the repair tools were able to recover the filesystem, but I was able to dump the files themselves to a new disk to recover them. Really not sure why, it was very strange.
I recently conducted system resource starvation tests where a compile process spun off enough threads to soak the system to the point it becomes unresponsive. I did over 100 forced power off tests while the Btrfs file system was being written to as part of that compile. Zero complaints: not on mount, not on scrubs, not with btrfs check, and not any while in normal operation following those power offs.
If you want to complain about Btrfs, complain about the man page warning to not use --repair without advice from a developer. You did know about that warning, right?
Once I ended up with a bunch of zero length files (presumably metadata was written before content?).
I also, multiple times ended up with errors related to full drives despite by drive not being full. Deleting snapshots seemed to help.
Then I went to a zfs fs on root and never had another problem.
My quite large 1tb multivolume, multisnapshot BTRFS fs never had any problems.
And it's quite aggressive cfg (big fs commit).
P.S. I do have backups though.
Why not putting poweroff in a cron task a bit before midnight so you don't uselessly risk hosing your file system? You can always restore your backup but it takes time!
[1] https://arstechnica.com/information-technology/2012/07/netfl...
Same thing happens with operating systems.
Why wouldn't you expect it to survive that? Is there a particular reason to believe those drives are broken? I.e., are they older consumer drives known to lie about cache flushes? do they have bad sectors? How have you abused it? What kind of load? Did you fill the filesystem (which another commenter mentioned seems to be a common element of most sad btrfs stories)? did your system frequently lose power while under write load?
Lacking more details, I'd just say one user experiencing 0 bugs in 5 years should be completely unremarkable. I expect filesystems to be very reliable, so a lot of people having stories of corruption means stay away from btrfs. Having some people with stories of no corruption doesn't really move the needle. Together, these stories still mean stay away from btrfs!
You want details from people experiencing zero problems, but you don't ask for details from people who are? That's a weird way to go about conducting the necessary autopsies, to discover and fix bugs.
Anyway, I monitor the upstream filesystems lists, and they all have bugs. They're all fixing bugs. They're all adding new features. And that introduces bugs that need fixing. It's not that remarkable, until of course someone suggests only one file system is to be avoided, while also providing no details, but depends on conjecture.
I don't need to ask people who've had problems because I've had them myself, in unremarkable circumstances, a while back. I'm sure I could find reports on the mailing list as well, in which others have already asked for details.
Surely it depends on the btrfs implementation. e.g. Arch Linux getting daily kernel updates vs an enterprise distro
Down there, 2/3 of this hackersnews discussion (if you are patient to get there) you can see questions about production deployment of btrfs, with some VERY interesting answers of BIG deployments of btrfs. Read success confirmed with data. My takeaway from reading whole discussion:
* lot of people (individuals) praise of btrfs
* lot of people (ind.) tell about problems
* quite nice features/btrfs usage patterns, not matched even by zfs mentioned
* still for VM/DB you shall consider different approach (thin LVM + xfs or ext4) and slave machine WITH btrfs and snapshots on it
* quite many problems/deficienses of ZFS mentioned (apart fomr typical license/kernel inclusion)
* lot of new features on the way in recent kernels for btrfs
* btrfs is not dead
p.s. worth to comment that kernel 5.6 just received another huge new features batch for btrfs (async discard!)