On 7/9/20 2:11 PM, Josef Bacik wrote: >> >> From what I've gathered from these responses, btrfs is unique in that it is >> /expected/ that if anything goes wrong, the administrator should be prepared >> to scrape out remaining data, re-mkfs, and start over. If that's acceptable >> for the Fedora desktop, that's fine, but I consider it a risk that should not >> be ignored when evaluating this proposal. >> > > Agreed, it's the very first thing I said when I was asked what are the downsides. There's clearly more work to be done in the recovery arena. How often do disks fail for Fedora? Do we have that data? Is this a real risk? Nobody can say because Fedora doesn't have data. But again, let me reiterate that disk failures are far from the only reason that admins need capable filesystem repair tools, in general. We see users running fsck all the time, for various reasons. I can't back it up, but my hunch is that bugs and misconfigurations (i.e. write cache) are more often the root cause for filesystem inconsistencies. IMHO, focusing on physical disk failure rates is focusing too narrowly, but I suppose I'm just joining the chorus of hunches and anecdotes now. -Eric > Facebook does however have that data, and it's a microscopically small percentage. I agree that Facebook is vastly different from Fedora from a recovery standpoint, but our workloads and hardware I think extrapolate to the normal Fedora user quite well. We drive the disks harder than the normal Fedora user does of course, but in the end we're updating packages, taking snapshots, and building code. We're just doing it at 1000x what a normal Fedora user does. Thanks, > > Josef _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
