On 7/9/20 3:38 PM, Chris Murphy wrote: > On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >> 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. > Actually there's quite a lot of evidence of this, even though there's > no precise estimate - not least of which these populations are > constantly dying and reemerging, and can be batch (firmware version) > specific. This is only the most recent such story on linux-btrfs@ (and > warning, this reads like an alien autopsy): > > https://lore.kernel.org/linux-btrfs/20200708034407.GE10769@xxxxxxxxxxxxxx/ > > fsck.btrfs is a no op, same as fsck.xfs. And recently the actual > repair utility dissuades users from running it casually. Honestly, that's not relevant. They are no-ops because they do not need to be run at boot time after an unclean shutdown, because the filesystems are explicitly designed to handle that. This is clearly stated in the man page, the script itself, and the commit log. In fact fsck.btrfs was copied from fsck.xfs. (Honestly fsck.ext[34] could be a no-op too, but for $REASONS it chooses to do journal replay in userspace instead, via fsck.) They are no-ops for this reason, and /not/ because fsck isn't /ever/ expected to be needed. -Eric _______________________________________________ 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
