After having had this happen a couple of times already, I replaced a drive with a fresh new drive. The rebuild of that drive just finished, so I powered down, powered up again... and BOOM. Same error for the same disk number, even though it's a different physical drive.

 

I think it's highly unlikely that the new drive failed in exactly the same way, so what might be going on here?

 

If the partition layout really is bad (again!), are there any partition repair tools that can be used rather than rebuilding the drive yet again?

I was just getting ready to replace ALL of the drives in this ten-year-old array, all of them 4TB, with new 8TB drives, starting from scratch, keeping the old 4TB drives offline as an extra backup. But since swapping one of the 4TB drives with a new 4TB drive didn't fix the problem for that one drive slot, I'm beginning to fear that perhaps I'll keep getting the same failure even with all new drives.

Could some corruption in my Unraid system itself be to blame? Can a SATA controller go bad in such a way that power cycling leads to corrupt drives?

Is the reiserfs file system particularly vulnerable to such failures, so that when I start from scratch with 8TB drives using xfs instead, that might help prevent a recurrence of this problem?

Please post the diagnostics mostly to see the hardware used.

In around 13-14 hours I'll have the results of an experiment to see if the SATA controller is at fault.

I disconnected the SATA cable from the newly-failed drive, marked that cable as potentially bad with a piece of tape (not likely the cable itself being bad, but the associated port), and then connected an as-yet-unused SATA port to the hot-swap drive bay of the failed drive. I put the OLD drive back into this position, the one I thought was itself failing, started my array back up, and now that drive is being rebuilt.

 

When the rebuild is complete, another power cycle might tell the story.

 

Another reason I'm suspicious of the controller, and that one particular port on the controller, is that I ended up with TWO "Unsupported partition layout" drives when I tried to swap an old but empty drive into the same drive bay as the first failed drive, got the same error, put that drive back in its old bay, and then found I'd doubled my failed disk problem.

Fortunately, this troublesome array is only being used as a backup for a newer, much more reliable array, an array that additionally has two single-drive backups (one now slightly out-of-date copy a friend is holding for me).

1 hour ago, JorgeB said:

Please post the diagnostics mostly to see the hardware used.

 

trantor-diagnostics-20230705-1249.zip

Assuming that the issue has been happening like this time with the disk connected to this controler:

 

[1103:2300] (rev 02)
    Subsystem: Marvell Technology Group Ltd. RocketRAID 230x 4 Port SATA-II Controller [11ab:11ab]
    Kernel driver in use: sata_mv
    Kernel modules: sata_mv

 

It would be main main suspect.

My experiment led to another failure, but it was a different port on the same controller I had been trying, not a different controller.

 

I could have experimented further (I have both motherboard SATA ports and an extra ports on a PCI card), but I decided to go straight to buying a new motherboard to go along with the new 8TB drives I had already ordered. Now all that remains of the old NAS I tried to press back into service as a backup system is the case, power supply, and the hot-swap drive bays. Ah, well!

 

It's a really nice case at least. I can't find anything like this anymore. It's standard PC tower, but the entire front side of the case can be used, top to bottom, for up to 8 accessible drive bays. I'd have loved to have gotten another one like it for my new NAS, but couldn't find one anywhere.

I'd never have guessed a SATA controller could go bad in such a way that it would repeatedly corrupt hard drives simply by powering up or powering down.