Hi

 

I have an array of 16 HDDs, 3TBs and 2TBs mostly.

 

my unRAID is running in a virtual machine on ESXi host.

 

THe other day, my host crashed for some reason, and when i started the unRAID again, and started a parity check, the host again crashed.

 

Anyways, i started the parity-check again, and so far, it's at 42% since 3 days

 

Total size:	3	TB
Current position:	1.27	TB (42%)
Estimated speed:	5.95	MB/sec
Estimated finish:	4843	minutes
Sync errors corrected:	0	

 

Is this normal? Could it be this slow because it crashed again during the first parity-check?

That seems unreasonably slow. I don't think the crash should have impact anything as it's basically doing a compare between your parity drive and your data. Whether it successfully completed a repair or not before crashing again shouldn't be a major issue.

 

So there are two possibilities I can think of (there may be more, but these are top of head). The first is that the CPU is pegged on the host and the UnRAID VM is just trickling along. Second is there are issues in reading/writing to disks and there are a large number of retries happening.

 

Can you post a syslog from UnRAID? It may give an indication of what the issue is.

 

HiSoC8Y: What kind of hardware do you have?

 

What is you parity check speed usually?

Jun 30 20:33:52 Tower kernel: sd 0:0:2:0: task abort: SUCCESS scmd(ec5b0f00)
Jun 30 20:34:24 Tower kernel: sd 0:0:4:0: attempting task abort! scmd(f6dfa900)
Jun 30 20:34:24 Tower kernel: sd 0:0:4:0: [sdf] CDB: 
Jun 30 20:34:24 Tower kernel: cdb[0]=0x28: 28 00 8e b0 af 10 00 04 00 00
Jun 30 20:34:24 Tower kernel: scsi target0:0:4: handle(0x000e), sas_address(0x5001e674641b1fe8), phy(
Jun 30 20:34:24 Tower kernel: scsi target0:0:4: enclosure_logical_id(0x5001e674641b1fff), slot(
Jun 30 20:34:25 Tower kernel: sd 0:0:4:0: task abort: SUCCESS scmd(f6dfa900)
Jun 30 20:34:57 Tower kernel: sd 0:0:2:0: attempting task abort! scmd(f7540900)
Jun 30 20:34:57 Tower kernel: sd 0:0:2:0: [sdd] CDB: 
Jun 30 20:34:57 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 8e b3 c1 28 00 00 03 e8 00 00
Jun 30 20:34:57 Tower kernel: scsi target0:0:2: handle(0x000c), sas_address(0x5001e674641b1fe6), phy(6)
Jun 30 20:34:57 Tower kernel: scsi target0:0:2: enclosure_logical_id(0x5001e674641b1fff), slot(6)
Jun 30 20:34:58 Tower kernel: sd 0:0:2:0: task abort: SUCCESS scmd(f7540900)
Jun 30 20:35:29 Tower kernel: sd 0:0:2:0: attempting task abort! scmd(d44dcb40)
Jun 30 20:35:29 Tower kernel: sd 0:0:2:0: [sdd] CDB: 
Jun 30 20:35:29 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 8e b4 2f 20 00 00 04 00 00 00
Jun 30 20:35:29 Tower kernel: scsi target0:0:2: handle(0x000c), sas_address(0x5001e674641b1fe6), phy(6)
Jun 30 20:35:29 Tower kernel: scsi target0:0:2: enclosure_logical_id(0x5001e674641b1fff), slot(6)
Jun 30 20:35:30 Tower kernel: sd 0:0:2:0: task abort: SUCCESS scmd(d44dcb40)
Jun 30 20:35:30 Tower kernel: sd 0:0:5:0: attempting task abort! scmd(d44dc600)
Jun 30 20:35:30 Tower kernel: sd 0:0:5:0: [sdg] CDB: 
Jun 30 20:35:30 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 8e b4 2f 20 00 00 00 b0 00 00
Jun 30 20:35:30 Tower kernel: scsi target0:0:5: handle(0x000f), sas_address(0x5001e674641b1fe9), phy(9)
Jun 30 20:35:30 Tower kernel: scsi target0:0:5: enclosure_logical_id(0x5001e674641b1fff), slot(9)
Jun 30 20:35:30 Tower kernel: sd 0:0:5:0: task abort: SUCCESS scmd(d44dc600)
Jun 30 20:36:02 Tower kernel: sd 0:0:3:0: attempting task abort! scmd(f6cfc300)
Jun 30 20:36:02 Tower kernel: sd 0:0:3:0: [sde] CDB: 
Jun 30 20:36:02 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 8e b6 3f 20 00 00 03 58 00 00
Jun 30 20:36:02 Tower kernel: scsi target0:0:3: handle(0x000d), sas_address(0x5001e674641b1fe7), phy(7)
Jun 30 20:36:02 Tower kernel: scsi target0:0:3: enclosure_logical_id(0x5001e674641b1fff), slot(7)
Jun 30 20:36:03 Tower kernel: sd 0:0:3:0: task abort: SUCCESS scmd(f6cfc300)
Jun 30 20:36:40 Tower kernel: sd 0:0:8:0: attempting task abort! scmd(f616c600)
Jun 30 20:36:40 Tower kernel: sd 0:0:8:0: [sdj] CDB: 
Jun 30 20:36:40 Tower kernel: cdb[0]=0x28: 28 00 8e c3 95 a8 00 01 b8 00
Jun 30 20:36:40 Tower kernel: scsi target0:0:8: handle(0x0012), sas_address(0x5001e674641b1fec), phy(12)
Jun 30 20:36:40 Tower kernel: scsi target0:0:8: enclosure_logical_id(0x5001e674641b1fff), slot(12)
Jun 30 20:36:40 Tower kernel: sd 0:0:8:0: task abort: SUCCESS scmd(f616c600)
Jun 30 20:37:13 Tower kernel: sd 0:0:6:0: attempting task abort! scmd(f636b000)
Jun 30 20:37:13 Tower kernel: sd 0:0:6:0: [sdh] CDB: 
Jun 30 20:37:13 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 8e c7 36 a8 00 00 03 a0 00 00
Jun 30 20:37:13 Tower kernel: scsi target0:0:6: handle(0x0010), sas_address(0x5001e674641b1fea), phy(10)
Jun 30 20:37:13 Tower kernel: scsi target0:0:6: enclosure_logical_id(0x5001e674641b1fff), slot(10)
Jun 30 20:37:14 Tower kernel: sd 0:0:6:0: task abort: SUCCESS scmd(f636b000)
Jun 30 20:37:14 Tower kernel: sd 0:0:12:0: attempting task abort! scmd(f3f13000)
Jun 30 20:37:14 Tower kernel: sd 0:0:12:0: [sdn] CDB: 
Jun 30 20:37:14 Tower kernel: cdb[0]=0x28: 28 00 8e c7 36 a8 00 04 00 00
Jun 30 20:37:14 Tower kernel: scsi target0:0:12: handle(0x0016), sas_address(0x5001e674641b1ff1), phy(17)
Jun 30 20:37:14 Tower kernel: scsi target0:0:12: enclosure_logical_id(0x5001e674641b1fff), slot(17)
Jun 30 20:37:14 Tower kernel: sd 0:0:12:0: task abort: SUCCESS scmd(f3f13000)
Jun 30 20:37:48 Tower kernel: sd 0:0:13:0: attempting task abort! scmd(f75b7780)
Jun 30 20:37:48 Tower kernel: sd 0:0:13:0: [sdo] CDB: 
Jun 30 20:37:48 Tower kernel: cdb[0]=0x28: 28 00 8e ca 57 a8 00 04 00 00
Jun 30 20:37:48 Tower kernel: scsi target0:0:13: handle(0x0017), sas_address(0x5001e674641b1ff2), phy(18)
Jun 30 20:37:48 Tower kernel: scsi target0:0:13: enclosure_logical_id(0x5001e674641b1fff), slot(18)
Jun 30 20:37:48 Tower kernel: sd 0:0:13:0: task abort: SUCCESS scmd(f75b7780)
Jun 30 20:38:22 Tower kernel: sd 0:0:10:0: attempting task abort! scmd(f6dfab40)
Jun 30 20:38:22 Tower kernel: sd 0:0:10:0: [sdl] CDB: 
Jun 30 20:38:22 Tower kernel: cdb[0]=0x28: 28 00 8e d1 6a 90 00 04 00 00
Jun 30 20:38:22 Tower kernel: scsi target0:0:10: handle(0x0014), sas_address(0x5001e674641b1fee), phy(14)
Jun 30 20:38:22 Tower kernel: scsi target0:0:10: enclosure_logical_id(0x5001e674641b1fff), slot(14)
Jun 30 20:38:23 Tower kernel: sd 0:0:10:0: task abort: SUCCESS scmd(f6dfab40)
Jun 30 20:38:58 Tower kernel: sd 0:0:8:0: attempting task abort! scmd(f7429cc0)
Jun 30 20:38:58 Tower kernel: sd 0:0:8:0: [sdj] CDB: 

 

the sys log is full of similar msgs as this.

 

what is it?

I am not sure what those mean. someone better versed in syslogs will likely need to post.

 

I would still suggest you post a full syslog though. What may be innocuous to you may have meaning to someone who can read syslogs properly.

 

Do you have a SAS card that could be loose?

hi

 

I have the Dell PERC H200 card, with an intel expander.

 

btw, i stopped the parity-check, and shutdown the server, removed all memory, the cards and reinstalled.  powered up, and tested the parity-check again, no luck, same issue.

 

any idea?

to add more details, I'm using the Intel Expander RES2SV240 with a Dell 6Gbps Dell H200 (IT mode).

 

Things were working fine. 

 

the changes I made.

 

1.) i added 5 HDDs (2 TB disks) to the array 2 weeks back.

2.) After the first esxi crash i mentioned, i updated the esxi 5.5 to the latest release (1881737).

Power support not handling the  added drives?

Hmmm

 

I was just thinking.

 

Before I added the new drives (6 drives), I have a total of 11 drives installed (including parity drive).

 

When I added the 6 drives, total drives are 17 HDDs. 

 

I was reading about my SAS card, Dell Perc H200, on the dell website, it's mentioned that the maximum drives supported is 16 drives.

 

http://www.dell.com/learn/us/en/04/campaigns/dell-raid-controllers

 

So could this be the issue?

Ok guys, I solved the slow parity issue.  Basically it was what I was thinking.  My Dell Perc H200 card can support up to 16 drives, and I had 17 drives when i was facing the issue.  I removed one drive and it worked. Parity was jumping from 9 MBps to 60 MBps (readings from unRAID GUI).