On Wed, Nov 29, 2017 at 10:28 PM, Klaus Agnoletti <klaus@xxxxxxxxxxxx> wrote: > Hi Chris, > >> >> I assume when you get that, either when deleting the device or >> scrubbing, that you also see the device unrecoverable read error in >> dmesg, as originally reported. If the drive must have the information >> on that lost sector, and you can't increase SCT ERC time (as well as >> the kernel SCSI command timer), or increasing it doesn't help, then >> that data is lost. It's plausible btrfs check repair is smart enough >> to be able to reconstruct this missing data, but I suspect it isn't >> yet that capable. > > That's the 'fun' part: I don't get any kernel messages after changing > the disk, hence my assumption that it's a relatively small, logical > error somewhere on the fs. I don't see how you get an IO error in user space without the kernel reporting the source of that IO error, whatever it is. > >> >> So my recommendation is to prepare to lose the file system. Which >> means backing up whatever you can while it's still working, such as it >> is. > > Yeah, luckily I can temporarily borrow a couple of 3TB disks to host > the data while I rebuild the fs. So that will probably be what I do. > > It there any way I can remove just files with bad data from the disk > error so I just get those out of the way? If Btrfs detects corruption of data extents, it will tell you the exact path to file names affected, as kernel messages. If you aren't getting that, then it's some other problem. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
