Jump to content

Insanely slow speeds during rebuild after disk swap [OS build 6.6.6]


3560freak

Recommended Posts

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.

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment

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?

Link to comment

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?

Link to comment
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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment
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.

Link to comment

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.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...