On 3 Jan 2024 13:25 -0700, from charlescur...@charlescurley.com (Charles Curley): >> As a background process, try running something like >> >> # ionice find / -xdev -type f -exec cat {} + >/dev/null > > That would only reach files on the partition where it is run.
I covered that on the next few lines, which you choose not to quote. > Since there is another operating system on this drive, That kind of information might be helpful to include up front. > and there are parts of > the drive normally inaccessible to any operating system, That's true, but it would have told you about any error in any accessible data _and_ also told you which file or directory was affected if that was the case. If the error is in an inaccessible portion of the drive and the system is working normally aside from a note in SMART data, then it would stand to reason that the error would be in an unused location; thereby not likely to affect usage (because a known bad spot would be reallocated elsewhere by the firmware on the next write). Also, badblocks too will only deal with user-accessible blocks; if the drive already had remapped a bad location, for example as a part of a write to an identified bad block, the original error would be invisible to badblocks even if it still was an error. On 3 Jan 2024 16:27 -0700, from charlescur...@charlescurley.com (Charles Curley): > OOPS! -w is the destructive test. I now have a hard drive full of 0x00s. After restoring your most recent backup, consider doing a fstrim to TRIM unused blocks. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”