I am trying to upgrade to a 6tb parity drive from 4tb using an HGST NAS drive. Rebuild starts at normal speeds, but at some point it drops down to KB/Sec. Thinking maybe the drive went bad I killed it, moved the drive to my desktop, and ran a wipe pass on it, but performance remained consistent through the entire drive during this process and SMART info looked good.

 

I thought I would try it again, so put the drive back in, started a parity rebuild, same thing. Starts off at normal speed, and at some point drops to KB/sec.  I believe the first time it showed it was only in the 1.xtb range of rebuilding... This time it appears it made it to 2.x tb.  Motherboard is a SuperMicro X8SIL-F and uses Supermicro AOC-SASLP-MV8 controller cards.  Without ripping the case open I can't say for sure what controller the port is plugged into. I have done rebuilds and added a drive while running 6.0.0 recently, not sure if it was 6.0.1 though the last time a rebuild happened.

 

Any ideas? Including my diagnostics.

stlo-unraid2-diagnostics-20150724-0725.zip

I noticed when it drops to the KB/sec rebuild it looks like the temperature reading shows blank for the parity drive and SMART data won't load.  When I attempt to stop the rebuild the system is locked up forcing a manual shutdown.

 

For time being I have put the 4tb drive back in to allow it to rebuild again and get back to a parity protected array

The rebuild can only go as fast as the slowest drive, so that usually means it wasn't limited by your parity drive, but by another drive having problems.  I checked your syslog, no obvious problems there, quite clean (just a quick review, might have missed something).  I checked the SMART reports and I don't see any evidence of a troubled drive slowing it down.  But your new Hitachi's are having compatibility issues with the current version of SMART tools.  They are both connected to a SAS card, try connecting them to motherboard ports (you just happen to have 2 empty ones).

 

It may be that you only need a SMART database update, and I can't recall how that's done, so hoping someone else will pop in with that info.  Right now, the Hitachi 4TB gets partial info, and what shows is excellent.  The 6TB isn't showing anything at all, and I suppose that could be affecting its responsiveness.  I would have expected that to show up in the syslog though.

I've put the following lines in my go file

 

# Update SMART database
/usr/sbin/update-smart-drivedb

I get this:

 

root@rack:~# /usr/sbin/update-smart-drivedb
/usr/sbin/update-smart-drivedb: download from trunk failed (HTTP error)

 

Is it just me?

Is it just me?

 

No, I get the same. Plenty of people around the web seem to have the same issue as well.

 

Edit: Repository still offline, restoration in progress. Should finish any day now...

Looks like I'm having similar stability issues with the 4tb drive now.. So something is giving me issues.  I had done a couple parity checks before replacing the drive, so it will be frustrating if I end up with a failing hard drive that is causing these problems and I can't recover the data manually.

 

I am seeing the same Temperature reading disappearing with the 4tb drive as well. I wonder if this could be a failing port/cable for the slot I use for parity. These are all hot swap ports on a 24 drive case.  I'm technically not back in the office until August but I may drop in to try and move the parity drive to another slot before I depart.

So I decided to kick off a Long SMART Test on each drive, sure enough a handful of them claim aborted by system, whereas others continue to run. I tried to find a pattern such as all being connected to the same controller card but that doesn't appear to be the case. I wonder if this could be a power supply issue causing this strangeness.

 

Disk1, 2, 3, 4, 5, 8 and 17 all stopped running the Long Smart test... Other drives are still showing in progress.

If the disks are set to spin down the test will be aborted.

Ok, thought it was strange some were running still while others were not... But I think I now have a better idea of what is going on.

 

Disk3 is now showing as unmountable after the last reboot, and reiserfschk suggest the rebuild-sb option.  Of course this problem happened during a parity upgrade so I need to attempt and recover as much as I can as I have no other way to recover this data.  Uploading another diagnostic report now that I have a drive claiming unmountable.

 

Any advice on recovering this data and forcing it to mount?  the rebuild-sb option had a lot of options to it so I opted to not complete this process as of yet.

 

stlo-unraid2-diagnostics-20150725-1519.zip

Are you certain that the disks are RFS formatted? The current default is XFS.

Yes, it is reiser, none of my drives have been converts to XFS and I haven't added a new one since it was the default

Turns out I had some corrupted file systems that I documented in more detail here.

 

http://lime-technology.com/forum/index.php?topic=41955.msg400882#msg400882

 

Parity is once again at a happy point on a 6tb drive.