Hi everyone!

 

So, I'm running my Unraid server with one parity drive and 3 array drives, all 4 of them being Seagate Ironwolfs, the 4 TB, 5900 RPM variant. 

For one of them (Disk 2), SMART started reporting pending and reported uncorrect sectors. At first, it was a couple and so I thought I had time. But, of course, you can see where this is going, I was too late and the drive got disabled. From 6 or 7 bad sectors, it jumped to 72 reallocated and 64 more pending. 

 

At the moment that that happened, the faulty drive reported a full capacity of ~28 GBs, which was strikingly low compared to the other 2 drives, 179 GB and 1,35 TB respectively. Maybe this is more related to the way I have setup my shares, but I have a secret hope that the OS 'realized' the drive was dying and moved data to the other 2 disks. Don't know if Unraid works that way, would be nice if anyone can confirm that. That's my first question. 

 

I'm pretty certain that the drive got disabled during parity check, because it was the first time ever that parity was paused at 80+% . I resumed it and it actually finished without reporting other errors. 

 

So, I'm now in a state where I have a valid parity check (it has run once more since this incident) and a faulty drive. I have already ordered a replacement and my main question is related to what will happen once I pop in the new drive and I try to rebuild it after pre-clear. Should I expect that I get valid data back in disk 2, or should I expect some data loss? Especially now, that parity has run once more after the disk got disabled, has it overwritten the good data of that disk?

 

Thank you for any answers in advance.

1 hour ago, EarendilD said:

secret hope that the OS 'realized' the drive was dying and moved data to the other 2 disks. Don't know if Unraid works that way

No it doesn't. And nobody would want it to if they considered all the possible complications.

 

1 hour ago, EarendilD said:

Especially now, that parity has run once more after the disk got disabled

Were these correcting parity checks? Why were you running parity checks anyway?

 

I don't think it can even do a parity check if you have a disabled disk unless you have dual parity. Are you sure it wasn't doing a read check instead?

 

Attach diagnostics to your NEXT post in this thread.

8 hours ago, trurl said:

 Are you sure it wasn't doing a read check instead?

Indeed it was, but my confusion came from the terminology used until Unraid OS v6.10 (see attached picture).

 

Diagnostics are attached. Thank you for your time and answers!

homenas-unraid-diagnostics-20221019-1340.zip

I wouldn't run any check when in a degraded state already, last thing you want is straining the drives and have another fail before you can rebuild the bad one...

 

Anyway it will rebuild exactly what you see on the emulated drive, which is what was on it when it got disabled.

Edited October 19, 20223 yr by Kilrah

38 minutes ago, Kilrah said:

it will rebuild exactly what you see on the emulated drive, which is what was on it when it got disabled

The emulated drive can be modified by writes, copies, moves, deletes, even formats (all write operations). Any write operations to the emulated drive after the drive became disabled are also part of the rebuild. So it is not necessarily what was on the physical disk when it got disabled.

 

The whole point of parity emulation is so things continue to work normally and any additional changes to the array disk are not lost.

Yes, improper wording probably - what I meant is that if the emulated drive doesn't have what OP expects the rebuild won't change that.

44 minutes ago, Kilrah said:

it will rebuild exactly what you see on the emulated drive

emulated disk2 is mounted.

 

11 hours ago, EarendilD said:

low compared to the other 2 drives

And empty or mostly so. Apparently that is expected.

 

11 hours ago, EarendilD said:

related to the way I have setup my shares

Highwater allocation will write disk1 first which is expected and perfectly fine. Highwater is the default and the preferred allocation for most situations.

 

Not sure why disk3 seems to have slightly more data than disk2, possibly include/exclude share setting, or maybe writes directly to the disk instead of to a user share.

 

You can see how much of each disk is used by each user share by going to the User Shares page and clicking Compute All button at bottom. It might be useful to see a screenshot of that to get a better idea how your shares are working.

 

Oct 17 12:45:12 HomeNAS-unRAID root: Fix Common Problems: Warning: NerdPack.plg Not Compatible with Unraid version 6.11.1

NerdPack is deprecated on 6.11. Uninstall and get the new NerdTools plugin.

 

You should definitely replace disk2. Be careful with connections. Then rebuild should be OK.

30 minutes ago, trurl said:

You should definitely replace disk2. Be careful with connections. Then rebuild should be OK.

 

@EarendilD, I am quoting this for emphasis!  After you install the replacement drive, check every SATA connector to make sure that it is fully and firmly seated.  SATA connectors are notorious for working loose when the leads are disturbed in any fashion.  The minute or two required to reseat each connector can save hours of frustration later. 

Thank you all so much for your input! I have already disabled Read check for now, as suggested. @Frank1940 I'll definitely pay attention to your point about SATA connectors!! I have had grief with that, unrelated to Unraid, so I'm always cautious. You only learn that if someone tells you or by experience.

 

Thank you also for your insights on how parity works. I've watched a great video from SpaceInvaderOne and thought I got the gist of it, but didn't know what would happen in my case. I'll tag this as solved. But I'll report back after pre-clearing the new drive and rebuilding.

4 hours ago, EarendilD said:

after pre-clearing the new drive and rebuilding.

Preclear is only a test of the drive in this situation, a clear drive is only required when adding to a new slot.