4 ms·

> So you don't expect to accrue on the order of 1000 machine-hours in your deployment? The 1000 number came from you. I have no idea where you got it from. I s

> So you don't expect to accrue on the order of 1000 machine-hours in your deployment? The 1000 number came from you. I have no idea where you got it from. I suspect the "real number" is several orders of magnitude higher, but I have no idea, and it's sort of artificial in the first place. My overarching point is that mine is such a vanishingly small portion of the universe of machines running btrfs that I am virtually guaranteed that bugs will be found and fixed before they affect me, exactly as happened here. Unless you run a rather large business, that's probably true for you too. The filesystem with the most users has the least bugs. Nothing with the feature set of btrfs has even 1% the real world deployment footprint it does. > If you have millions of users, some of them will hit it within hours or even minutes after boot! This is weirdly sensationalist: I don't get it. Nobody dies when their filesystem gets corrupted. Nobody even loses money, unless they've been negligent. At worst it's a nuisance to restore a backup.

lxgr 3y ago
> The 1000 number came from you. I have no idea where you got it from, It's an arbitrary example of an error rate you'd have a 90% chance of missing in your sample size of 100 machine-hours, yet much too high for almost any meaningful application. I have no idea what the actual error rate of that btrfs bug is; my only point is that your original assertion of "I've experienced 100 error-free hours, so this is a non-issue for me and my users" is a non sequitur. > This is weirdly sensationalist: I don't get it. Nobody dies when their filesystem gets corrupted. Nobody even loses money, unless they've been negligent. I don't know what to say to that other than that I wish I had your optimism on reliable system design practices across various industries. Maybe there's a parallel universe where people treat every file system as having an error rate of something like "data corruption/loss once every four days", but it's not the one I'm familiar with. For better or worse, the bar for file system reliability is much, much, much, much higher than anything you could reasonably produce empirical data for unless you're operating at Google/AWS etc. scale.
- jcalvinowens 3y ago
  > "I've experienced 100 error-free hours, so this is a non-issue for me and my users" It's a statement of fact: it has been a non-issue for me. If you're like me, it's statistically reasonable to assume it will be a non-issue for you too. Also, no users, just me. "Proabably okay" is more than good enough for me, and I'm sure many people have similar requirements (clearly not you). I have no optimism, just no empathy for the negligent: I learned my lesson with backups a long time ago. Some people blame the filesystem instead of their backup practices when their data is corrupted, but I think that's naive. The filesystem did you a favor, fix your shit. Next time it will be your NAS power supply frying your storage. It's also a double edged sword: the more reliable a filesystem is, the longer users can get away without backups before being bitten, and the greater their ultimate loss will be.
  - lxgr 3y ago
    > It's a statement of fact: it has been a non-issue for me. Yes... > If you're like me, it's statistically reasonable to assume it will be a non-issue for you too. No! This simply does not follow from the first statement, statistically or otherwise. You and I might or might not be fine; you having been fine for 100 hours on the same configuration just offers next-to-zero predictive power for that.
    - jcalvinowens 3y ago
      > No! This simply does not follow from the first statement, statistically or otherwise. > You and I might or might not be fine; you having been fine for 100 hours on the same configuration just offers next-to-zero predictive power for that. You're missing the forest for the trees here. It is predictive ON AVERAGE. I don't care about the worst case like you do: I only care about the expected case. If I died when my filesystem got corrupted... I would hope it's obvious I wouldn't approach it this way. Adding to this: my laptop has this btrfs bug right now. I'm not going to do anything about it, because it's not worth 20 minutes of my time to rebuild my kernel for a bug that is unlikely to bite before I get the fix in 6.9-rc1, and would only cost me 30 minutes of time in the worst case if it did. I'll update if it bites me. I've bet on much worse poker hands :)
bmicraft 3y ago
> Nothing with the feature set of btrfs has even 1% the real world deployment footprint it does. So you haven't heard of zfs then?

lxgr 3y ago

> The 1000 number came from you. I have no idea where you got it from, It's an arbitrary example of an error rate you'd have a 90% chance of missing in your sample size of 100 machine-hours, yet much too high for almost any meaningful application. I have no idea what the actual error rate of that btrfs bug is; my only point is that your original assertion of "I've experienced 100 error-free hours, so this is a non-issue for me and my users" is a non sequitur. > This is weirdly sensationalist: I don't get it. Nobody dies when their filesystem gets corrupted. Nobody even loses money, unless they've been negligent. I don't know what to say to that other than that I wish I had your optimism on reliable system design practices across various industries. Maybe there's a parallel universe where people treat every file system as having an error rate of something like "data corruption/loss once every four days", but it's not the one I'm familiar with. For better or worse, the bar for file system reliability is much, much, much, much higher than anything you could reasonably produce empirical data for unless you're operating at Google/AWS etc. scale.

jcalvinowens 3y ago
> "I've experienced 100 error-free hours, so this is a non-issue for me and my users" It's a statement of fact: it has been a non-issue for me. If you're like me, it's statistically reasonable to assume it will be a non-issue for you too. Also, no users, just me. "Proabably okay" is more than good enough for me, and I'm sure many people have similar requirements (clearly not you). I have no optimism, just no empathy for the negligent: I learned my lesson with backups a long time ago. Some people blame the filesystem instead of their backup practices when their data is corrupted, but I think that's naive. The filesystem did you a favor, fix your shit. Next time it will be your NAS power supply frying your storage. It's also a double edged sword: the more reliable a filesystem is, the longer users can get away without backups before being bitten, and the greater their ultimate loss will be.
- lxgr 3y ago
  > It's a statement of fact: it has been a non-issue for me. Yes... > If you're like me, it's statistically reasonable to assume it will be a non-issue for you too. No! This simply does not follow from the first statement, statistically or otherwise. You and I might or might not be fine; you having been fine for 100 hours on the same configuration just offers next-to-zero predictive power for that.
  - jcalvinowens 3y ago
    > No! This simply does not follow from the first statement, statistically or otherwise. > You and I might or might not be fine; you having been fine for 100 hours on the same configuration just offers next-to-zero predictive power for that. You're missing the forest for the trees here. It is predictive ON AVERAGE. I don't care about the worst case like you do: I only care about the expected case. If I died when my filesystem got corrupted... I would hope it's obvious I wouldn't approach it this way. Adding to this: my laptop has this btrfs bug right now. I'm not going to do anything about it, because it's not worth 20 minutes of my time to rebuild my kernel for a bug that is unlikely to bite before I get the fix in 6.9-rc1, and would only cost me 30 minutes of time in the worst case if it did. I'll update if it bites me. I've bet on much worse poker hands :)

bmicraft 3y ago

> Nothing with the feature set of btrfs has even 1% the real world deployment footprint it does. So you haven't heard of zfs then?