I have just replaced a WD RED 4TB with a shucked 10TB Easystore and started the rebuild process (after preclearing 2 sessions).  I assumed that the rebuild would take some time, but the estimate finish fluctuates between 160 - 206 days at a rate of 350 - 600 KB/sec.  What in the world could be causing such an insanely slow re-build?  Prior to this I have never noticed the server running slow or failing parity checks.  A few days back I replaced the parity drive with another 10TB Easystore and it completed the parity rebuild in a normal amount of time.  Thanks for any tips/suggestions that you can provide.

Go to Tools - Diagnostics and attach the complete diagnostics zip to your next post.

4 minutes ago, trurl said:

Go to Tools - Diagnostics and attach the complete diagnostics zip to your next post.

Will do, thank you.  Do I need to edit anything out of the file (drive serial numbers or ethernet MAC addresses)?  Wouldn't want anyone taking advantage of those items if that matters.

19 minutes ago, 3560freak said:

Do I need to edit anything out of the file

no

System log attached.

tower2-diagnostics-20181213-2125.zip

Cancel the rebuild, replace cables or swap backplane on the parity disk and try again.

5 hours ago, johnnie.black said:

Cancel the rebuild, replace cables or swap backplane on the parity disk and try again.

Thank you johnnie.black.  Just to ensure I am understanding correctly, am I able to switch around physical positions of the disks on the backplane as long as the correct serial numbers are assigned to the proper (SDB/C/D/E) allocations?

 

Just to clarify I had the array up and running for the last week or so with the upgraded 10 TB disk as parity and nothing has changed except replacing one of the data drives with this other new 10 TB disk.  So based on the info provided in the syslog, the assumption is that something is wrong with the connection to the parity disk?

2 minutes ago, 3560freak said:

Just to ensure I am understanding correctly, am I able to switch around physical positions of the disks on the backplane as long as the correct serial numbers are assigned to the proper (SDB/C/D/E) allocations?

sd device letter is irrelevant. Unraid only uses the disk serial numbers to keep track of disk assignments.

5 minutes ago, 3560freak said:

So based on the info provided in the syslog, the assumption is that something is wrong with the connection to the parity disk?

Yes, there appears to be a connection issue, causing hundreds of ATA errors, disk itself look fine, so just use a different slot.

Thanks for the responses.  One more thing before I do any irreversible damage, am I able to just bring the array back up and restart/continue the re-build or do I need to reformat/clear disk that was being replaced?

Start the array and the rebuild will re-start from the beginning.

When I bring the array back up (after swapping disk positions) it looks like it wants to automatically start the parity/rebuild, however I am presented with this message and a check box for Unmountable disk present: Disk 1 • WDC_WD100EMAZ-00WJTA0_JEGKN59N (sde) Format will create a file system in all Unmountable disks, discarding all data currently on those disks.

 

Do I need to cancel rebuild/parity and check this box first, or will that message go away after the rebuild/parity completes?

You absolutely MUST NOT check that box!

Well then I am glad that I asked.  Thank you for the information.

 

Unfortunately I am not seeing much of an increase with the change in disk positions (hovering around 1 MB/sec).  I am puzzled, but can't have my array down for 100+ days while this one disk rebuilds (I had planned to replace all disks with 10 TB - one at a time obviously).  Any other suggestions?

 

I have another older UnRaid server that I can put all of the new disks in, create a new array, copy all content over the network, and then move the new disks over to the newer server I suppose. Although that seems like a painful task as well.

 

I don't think that this matters, but I am running an HP MicroServer Gen8.  Could it be that this device not support 10 TB drives?

Edited December 14, 20187 yr by 3560freak

Post new diagnostic

1 hour ago, 3560freak said:

Unfortunately I am not seeing much of an increase with the change in disk positions (hovering around 1 MB/sec). 

Then maybe there's something wrong with the disk.

 

1 hour ago, 3560freak said:

I don't think that this matters, but I am running an HP MicroServer Gen8.  Could it be that this device not support 10 TB drives?

Seems unlikely, since I assume there were no issues when you upgraded parity, and it's the same disk model and size, but like mentioned please post new diags.

Edited December 14, 20187 yr by johnnie.black

It has been my experience that some Dockers (especially anything that backs up data such as CrashPlan, Duplicati, etc) can drastically affect the speed on a parity build due to the fact that they scan the disks.  You may want to turn off all of your Dockers and passably disable cachedirs if you are running it until the rebuild completes.  This is all assuming you are no longer getting errors from the disks.

8 hours ago, johnnie.black said:

Then maybe there's something wrong with the disk.

 

Seems unlikely, since I assume there were no issues when you upgraded parity, and it's the same disk model and size, but like mentioned please post new diags.

Updated diag.  Thank you

tower2-diagnostics-20181214-1909.zip

UPDATE:

 

I replaced the potential questionable disk with another 10 TB Easystore shucked drive and am having the exact same results with this one.  I am truly at a loss at this point.  Can I put my old drive back in, connect the new drive via USB and copy all of the data over that way using the mover app or something similar?  I'm not sure what else to try at this point.

Edited December 15, 20187 yr by 3560freak

Previous diags the ATA errors were with the parity disk, you swapped positions between disk1 and parity, and now the errors are on disk1, which means the problem is likely that slot (ATA4).

 

I'm only familiar with the Gen7 Microserver, but see if you can reconnected the cables in the back of that slot.

 

On a second look, with more time, there are now errors on both ATA1 and ATA4, parity and disk1, so maybe there really is a compatibility issue with those 10TB disks and the Microserver.

 

It might also have something to do with 3.3v pin, but from what I can see the Microserver doens't have 3.3v on the backplane.

Edited December 15, 20187 yr by johnnie.black

I had checked into the 3.3v issue as well before installing and the Gen8 didn't seem to have that problem, so I also don't believe that this is the cause.  Would adding in a SAS/SATA controller card potentially solve the issue, I am currently using the built-in controller?  If so, do you have any chipset recommendations, or should I be looking at specific HP Gen8 forums to get that answer?  Thanks again for all of the help with this issue.

In an attempt to get this server back up and running for my multiple Plex users, I have now removed the "new" 10TB data drive and replaced it with the original 4TB, hoping to just go back to how it was before I tried this.  However UnRaid is now telling me that the disk 1 (original 4TB) is too small and must be replaced with the same size disk.  I am truly confused here.  I thought that data drive sizes didn't matter to UnRaid (mix and match whatever), so why would it be telling me this and not allowing my to start the array?  I feel that this server, that has been working fine for years, is completely hosed simply by trying to upgrade a data disk.  If I completely reverse everything (put the old 4TB parity drive back) will the server come back up, or has there been irreversible damage to the data now?

Edited December 15, 20187 yr by 3560freak

16 minutes ago, 3560freak said:

I thought that data drive sizes didn't matter to UnRaid (mix and match whatever), so why would it be telling me this and not allowing my to start the array?

You can't replace a larger drive with a smaller drive, you can do a new config with the older disk and resync parity, but any data written to the new disk since would be lost.

You can't replace a drive with a smaller drive because when you replace a drive Unraid assumes you want to rebuild to the replacement, so obviously a smaller drive isn't large enough for the rebuild.

 

As johnnie said. New Config basically resets your disk assignments and lets you assign anything anywhere, but parity typically has to be rebuilt when you do this.

So I just tried the New Config suggestions and am now receiving this error (from the syslog) over and over.

 

disk1 read error, sector=xxxxx

 

Log attached.

 

Did my old disk or entire server just crap the bed after attempting to upgrade these disks?

tower2-diagnostics-20181215-1720.zip

 

 

Should I stop the parity rebuild and try to re-seat the drive?

Edited December 15, 20187 yr by 3560freak