haas844

Good news, I replaced the SATA cable again and it seems to have fixed the issue. I'm currently running a non-correcting parity check at ~150MBps and ~3000 sync errors. Could I run into any issues running a correcting parity afterwards to remove the sync errors? @trurl is it best practice to keep those on the array? I do not use VMs, but run a few docker apps (Photoprism/Jellyfin) normally.

No, the disk has not shown that it is disabled. I tried running xfs repair again and to my surprise I think it worked. I restarted the array and Disk1 is now accessible, and I can see the files. I tried running a parity check (non-correcting), and it went very slowly (~300kbps), so I canceled it. Running a smart test on Disk 1 also yielded an error message (something about being interrupted by host), so I set the disk spindown to never and am in the process of running the extended test again. I've also tried switching the SATA data/power cables around (after a clean shutdown) to see if that would improve anything. unraidserver-diagnostics-20240126-1654.zip

I rebooted my system and Disk 1 become 'unmountable'. I checked the disk in maintenance mode, and attempted to run an xfs repair on the disk. This led to an error, so I ran -L to see if that would repair the drive (per the SpaceInvader One xfs repair video). After running -n again to check, it seems there are new errors with the disk, and the disk still refuses to mount. Is there anything I can do to fix this? I've attached a smart report that was completed before the xfs repair, and the output of the xfs repair. Thanks! ST14000NM001G-2KJ103_ZTM0ELAF-20240125-1934.txt xfsrepair.txt