> [1] “It works for me on my two disk mirror” is an anecdote, not data.
While that statement might well be correct that the quote is in fact an anecdote, the following is also an anecdote: ‘From what I’ve heard, BTRFS has a crazy long list of defects where it’ll lock up or corrupt data if you so much as look at it wrong.’
Made the mistake using btrfs for a Hadoop cluster at university in kernel 4.x times after reading that SLES uses it and after reading an interview on lwn with someone important, I think the maintainer at that time - that deemed it stable. This must be 10 or 12 years ago or so and it was a wild ride - crashes, manual recovery on 200 machines using clusterssh to get the partitions to mount again. Got out of disk space errors on a 16tb raid 1 (which is not a real raid1) with 5% usage - lot's of sweat I'd rather avoid. Should have just used ext4 in hindsight.
For me I decided to not touch it anymore after that experience. I'm sure there is a name for that bias but I don't care. Got burned badly. Lots of people had probably similar experiences and that's were that coming from. Reading the mailing list archives at that time might also be useful to convince yourself that it was more than anecdote.
I’m not disputing any discourse relating to the factual in/correctness of the anecdote, I’m pointing out that gp is providing an anecdote while disputing anecdotes that they don’t agree with.
Provide actual data that’s recent. Linux 4.x was what, 10 years ago? Cars are substantially safer now than they were 10/20/50 years ago, so whose to say your experience with a file system would be different?
> You probably just don't, as the alternatives are good and plenty.
Which cannot be said about file systems on Linux which support metadata+data checksum and repair though. As far as I'm aware the only file systems which could realistically be used are btrfs and zfs (bcachefs looks promising but not there yet). Zfs is not even a part of the kernel and you have to compile it yourself and hope it does actually compile against your kernel due to API changes.
What changed with respect to car safety compared to 2014? If anything, the recent trend of putting every control in touchscreen interfaces has made cars less safe.
It's unfortunately a very common anecdote over the last 10 years (and a similar experience to my own). And to be honest, it's a red flag with how this critical system component is being developed.
Yeah, an interesting scenario is that many people compare the btrfs behaviour to "never had issues with extfs". When in practice it's "extfs couldn't have told me about this issue even if it existed".
Assuming FSM is referring to defects, witnessing no defects increases confidence that no defects exist in the observed state.
Conversely, witnessing defects does not itself prove defects exist if the test cases were not scientific, it increases the confidence that defects exist but there exists some probability that an unrelated defect (bad ram, kernel error, hardware failure, solar flares) could have caused the issue.
But there’s also a lot of evidence to suggest Brtfs has had a lot of defects resolved in recent years, so it’s also important to note that as time moves forward, the amount of existing and likely rate of introducing new defects is likely to decrease.
I should add ive had minimal skin in this game until yesterday. I chose brtfs for two systems for snapshot support, but that’s in addition to regular backups on another host, because it’s silly to trust any single compute node regardless of file system.
No. It is referring to the Flying Spaghetti Monster, but is an analogy for anything including defects. This is discussion about epistemology not filesystems.
While that statement might well be correct that the quote is in fact an anecdote, the following is also an anecdote: ‘From what I’ve heard, BTRFS has a crazy long list of defects where it’ll lock up or corrupt data if you so much as look at it wrong.’