On Sun, Sep 20, 2020 at 11:07 AM Daniel Pocock <daniel@xxxxxxxxxx> wrote: > > > > Does Btrfs have any mechanism to help manage ERC settings in the drives > or is there any desire for Fedora to help users do this? File systems have nothing do with SCT ERC or the SCSI command timer. There's no mechanism at all. > I've typically used rc.local to check the settings on drives used in md > or btrfs arrays, e.g. Or udev rule. Part of the blame goes to drive vendors for producing drives that can take upwards of *minutes* of thinking to decide whether or not your data can be returned. But then particularly pernicious is the kernel's default 30 second command timer where it just assumes a non-response requires a link reset, thereby obliterating all state information for the drive in question. Over on linux-raid@ list, these mismatch comes up all the time. It prevents normal raid repair function from working, whether mdadm, LVM, or Btrfs (and presumably ZFS on Linux but I'm not certain) and eventually will result in loss of the array, for the typical mortal user. For desktop users, the mismatch is perhaps a non-factor because which is better? Early loss of a sector resulting in I/O error? Or an increasingly slow system as the sole warning sign of bad sectors accumulating until it results in the loss of multiple sectors? It's just not great either way. Meanwhile some of these behaviors have changed as SSD's have become more common. You're more likely to get transient bit flips as the early warning sign, and then either all zeros or garbage instead of your data. If you're lucky, the drive itself goes read-only (different than the file system reporting the fs has gone read only) leaving your data readable. -- Chris Murphy _______________________________________________ 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
