I'm running 4.1 on the original starter kit hardware; it seems that ever since moving onto 4.x versions I've had more problems with unRaid. Last night I booted up, had the machine on for about an hour and then tried to shutdown from the web interface. I go the "Wait" message, and then nothing else. I was unable to telnet in, and unable to ping the server. Refreshing the web interface resulted in a message about being unable to reach the server.

 

So I did a reset and of course unRaid went into a parity drive check, which usually takes at least 6 hours (11 disks of data), so I left it running overnight. The parity check was running fine for at least the first 10 minutes, because I refreshed the web interface and could see that it was making progress.

 

This morning, I was again unable to reach the server via web interface, telnet or pinging. So I held down the power button to switch off the server (no drive access lights were flashing).

 

I'm a bit stuck now - if I reboot, there's a distinct possibility that I will simply go through the same thing again. What if I upgrade to 4.2 without completing the parity check? It doesn't sound like a good idea to me, but I don't know what else I can change.

I suppose many of us would have checked the console, after determining that network connectivity was lost.  Since you don't mention anything about the console, I'm guessing you are running headless?  If so, it sounds like your next step should be to hook a monitor up, and determine what errors might be visible on, or available by tail'ing the syslog, or by trying other commands.

 

With a console, you can also use Joe's excellent unmenu script to check status, stop the array, and reboot or power down safely.

 

As to upgrading, I don't think it would hurt, and there's a slight chance it would help, because of the possibility of newer/better drivers.  Your 6 hours seems awfully long, although I don't know how big your disks are.  Examining a current syslog might show errors that are slowing down operation.

 

I'm running between 4 and 5 hours for a parity check on my all IDE based array with a 500 Gig parity drive.

6 hours does not sound unreasonable for a 750 Gig parity drive on a mostly IDE based array with an SATA parity drive. 

 

Odds are it will finish when it get through with the largest of his data drives. The time estimate is probably based on the parity drive size.

I'd reboot it again and go through the check - with a Telnet session open running Tail on th esyslog so that if an error occurs and it crashes you've got some idea as to what occured...

Regarding the parity drive check, I recall the initial estimate by the web server was about 460 minutes - 7 hours, 40 min. Speed was around 13,000 kB/s (not sure if the units are right, but the number is correct). Parity drive is Seagate 400GB IDE, as are most of the other disks.

 

Unfortunately when I retried on the morning mentioned in my original post, I couldn't access anything. The web interface froze almost immediately after it said the parity check had started, so I can't even telnet in. I don't want to try again in case I overwrite anything informative in the syslog. But of course, now I can't get to the syslog while it's on the server.

 

If I plug the unRaid flash drive into another PC, can I extract the syslog? It would be easier if I can do this on a Windows PC, but I could also run a live Linux distro to get this, if I had to.

The syslog is written to a file in a filesystem created in RAM.  It is gone as soon as soon as you power down the PC. It is not on the flash drive.

 

That is why it was suggested that you log in when you first boot the machine and run a "tail -f" commannd on the syslog on the system console.  That way, when/if it locks up again, the final messages in the log would be on the console's screen.

 

If your box has locked up, reboot it. You really have no other recourse unless you can telnet in.

 

Joe L.

FWIW that parity speed is about what my IDE system runs when it is checking parity. That system has 12 drives, much data, 2x Promise cards, some of the IDE are ATA100, some ATA133. That speed isn't unusual IMO and yes it takes forever. I've added one SATA drive to that system for parity run from the M/B, I will add others and perhaps use IDE to SATA adapters on those drives. There's a command posted elsewhere to increase cache that might help for day to day access. This system is on the original Intel board with a Gig of RAM and a slightly higher end Celeron than originally specced.

 

I've built a second system, this one on 4.2x (the other on 4.1). This one also has a Gig of RAM, a 3.4Gig CeleronD, is mostly SATA, so far no drives on the PCI BUS. No data in this one YET but I don't think that actually matters when doing parity. This system has 2 older IDE drives online, 4 SATA drives - all new and big (2x 750 2x 1TB). This system is currently parity checking at OVER 40K p/s and yes I've done this a few times. Not sure how typical this is but it seems screaming fast to me! I intend to do some access tests in the near future to compare but right now it is looking like my move to SATA is long overdue. I will be interested to see how things go when I begin using SATA to IDE adapters, if speeds stay up I may swap over everything! Filling it full of drives will be the big test, fingers crossed that speeds stay up

 

Anyway, just a data point for you. Your speeds aren't unusual but can get better with faster hardware it seems.

 

P.S. A friend runs an all SATA system and see high speeds too but claims that when his system has an IDE in the mix speeds plummet - mine have not and he's puzzled <shrug>

Upgraded to 4.2.1, and restarted. This time the parity check started, ran for a few minutes and then I lost the connection. However, I managed to telnet in first, and got this from the syslog after a ROOT LOGIN message:

 

Nov  8 21:41:53 Tower kernel: [  943.780619] hdh: dma_timer_expiry: dma status =

= 0x61

Nov  8 21:42:03 Tower kernel: [  953.760967] hdh: DMA timeout error

Nov  8 21:42:03 Tower kernel: [  953.760979] hdh: dma timeout error: status=0x2b

{ DeviceFault DataRequest Index Error }

Nov  8 21:42:03 Tower kernel: [  953.760986] hdh: dma timeout error: error=0x2b

{ TrackZeroNotFound AddrMarkNotFound }, LBAsect=8830589807403, high=526344, low=

2829099, sector=23879343

Nov  8 21:42:03 Tower kernel: [  953.761003] ide: failed opcode was: unknown

Nov  8 21:42:03 Tower kernel: [  953.761010] hdg: DMA disabled

Nov  8 21:42:03 Tower kernel: [  953.761014] hdh: DMA disabled

Nov  8 21:42:03 Tower kernel: [  953.761039] pdc202xx_new: Secondary channel res

et.

Nov  8 21:42:03 Tower kernel: [  953.910668] ide3: reset: success

Nov  8 21:42:24 Tower kernel: [  974.589951] hdh: dma_timer_expiry: dma status =

= 0x41

 

The above is the last line before the connection failed.

 

Looks like a problem with hdg and hdh - I think they're on the same port on the Promise controller card, so it might be a card or cable problem.

Mea culpa 

 

Looks like it was the IDE cable; it was one of those round ones which many here have warned against. When I built the unRaid it was the only one lying around which was long enough, and it worked fine through a few releases so I didn't think of changing it. After replacing it with a flat cable, the parity check ran and completed (no errors) and the server seems to be working fine again.

A Happy Thanksgiving to all our US brethren.

 

Unfortunately my relief was short-lived. I left unRaid running overnight, and in the morning found that I got disconnected from the network again, and nothing showed up on the console.

 

So I rebooted, the parity check started, I got in via telnet and started capturing the syslong. The parity check ran for a few minutes then I heard an ominous "thunk" sound from the server, repeated a few times, though not consistently as far as I could tell. It pays to sit near it sometimes  . The syslog showed this:

 

 

Tower login: tai^H^H^H

Password:

Login incorrect

 

Tower login: root

 

[Disconnect bypassed -- root login allowed.]

Linux 2.6.22.5.

root@Tower:~# tail -f /var/log/syslog

Nov 25 07:13:50 Tower kernel: [  67.409599] can't shrink filesystem on-line

Nov 25 07:13:50 Tower kernel: [  67.502654] can't shrink filesystem on-line

Nov 25 07:13:50 Tower kernel: [  67.603155] can't shrink filesystem on-line

Nov 25 07:13:50 Tower kernel: [  67.603510] can't shrink filesystem on-line

Nov 25 07:13:50 Tower kernel: [  67.603782] can't shrink filesystem on-line

Nov 25 07:13:50 Tower kernel: [  67.604059] can't shrink filesystem on-line

Nov 25 07:13:50 Tower emhttp[1094]: shcmd (19): killall -HUP smbd

Nov 25 07:14:19 Tower in.telnetd[1287]: connect from 192.168.2.37 (192.168.2.37)

Nov 25 07:14:40 Tower login[1300]: invalid password for `UNKNOWN'  on `pts/0' fr

om `192.168.2.37'

Nov 25 07:14:42 Tower login[1300]: ROOT LOGIN  on `pts/0' from `192.168.2.37'

Nov 25 07:34:02 Tower kernel: [ 1277.218009] hdh: dma_timer_expiry: dma status =

= 0x61

Nov 25 07:34:10 Tower login[1095]: ROOT LOGIN  on `tty1'

Nov 25 07:34:12 Tower kernel: [ 1287.198356] hdh: DMA timeout error

Nov 25 07:34:12 Tower kernel: [ 1287.198368] hdh: dma timeout error: status=0x43

{ DriveReady Index Error }

Nov 25 07:34:12 Tower kernel: [ 1287.198374] hdh: dma timeout error: error=0x43

{ UncorrectableError TrackZeroNotFound AddrMarkNotFound }, LBAsect=8830591386435

, high=526344, low=4408131, sector=33198407

Nov 25 07:34:12 Tower kernel: [ 1287.198393] ide: failed opcode was: unknown

Nov 25 07:34:12 Tower kernel: [ 1287.198399] end_request: I/O error, dev hdh, se

ctor 33198407

Nov 25 07:34:12 Tower kernel: [ 1287.209937] md7: read error!

Nov 25 07:34:12 Tower kernel: [ 1287.209943] handle_stripe read error: 33198344/

7, count: 1

Nov 25 07:34:12 Tower kernel: [ 1287.570532] hdh: task_in_intr: status=0x51 { Dr

iveReady SeekComplete Error }

Nov 25 07:34:12 Tower kernel: [ 1287.570541] hdh: task_in_intr: error=0x04 { Dri

veStatusError }

Nov 25 07:34:12 Tower kernel: [ 1287.570545] ide: failed opcode was: unknown

Nov 25 07:34:12 Tower kernel: [ 1287.870010] hdh: task_in_intr: status=0x51 { Dr

iveReady SeekComplete Error }

Nov 25 07:34:12 Tower kernel: [ 1287.870019] hdh: task_in_intr: error=0x04 { Dri

veStatusError }

Nov 25 07:34:12 Tower kernel: [ 1287.870022] ide: failed opcode was: unknown

Nov 25 07:34:13 Tower kernel: [ 1288.023563] hdh: task_in_intr: status=0x51 { Dr

iveReady SeekComplete Error }

Nov 25 07:34:13 Tower kernel: [ 1288.023571] hdh: task_in_intr: error=0x04 { Dri

veStatusError }

Nov 25 07:34:13 Tower kernel: [ 1288.023575] ide: failed opcode was: unknown

Nov 25 07:34:13 Tower kernel: [ 1288.177147] hdh: task_in_intr: status=0x51 { Dr

iveReady SeekComplete Error }

Nov 25 07:34:13 Tower kernel: [ 1288.177154] hdh: task_in_intr: error=0x04 { Dri

veStatusError }

Nov 25 07:34:13 Tower kernel: [ 1288.177158] ide: failed opcode was: unknown

Nov 25 07:34:13 Tower kernel: [ 1288.177165] hdg: DMA disabled

Nov 25 07:34:13 Tower kernel: [ 1288.177191] pdc202xx_new: Secondary channel res

et.

Nov 25 07:34:13 Tower kernel: [ 1288.326133] ide3: reset: success

Nov 25 07:34:33 Tower kernel: [ 1308.496418] hdh: dma_timer_expiry: dma status =

= 0x41

Nov 25 07:34:43 Tower kernel: [ 1318.476766] hdh: DMA timeout error

Nov 25 07:34:43 Tower kernel: [ 1318.476777] hdh: dma timeout error: status=0x3a

{ DeviceFault SeekComplete DataRequest Index }

Nov 25 07:34:43 Tower kernel: [ 1318.476783] ide: failed opcode was: unknown

Nov 25 07:34:43 Tower kernel: [ 1318.476789] hdh: DMA disabled

Nov 25 07:34:43 Tower kernel: [ 1318.476815] pdc202xx_new: Secondary channel res

et.

Nov 25 07:34:46 Tower kernel: [ 1321.770278] ide3: reset: success

Nov 25 07:35:07 Tower kernel: [ 1342.409638] hdh: dma_timer_expiry: dma status =

= 0x41

Nov 25 07:35:17 Tower kernel: [ 1352.389985] hdh: DMA timeout error

Nov 25 07:35:17 Tower kernel: [ 1352.389996] hdh: dma timeout error: status=0x3a

{ DeviceFault SeekComplete DataRequest Index }

Nov 25 07:35:17 Tower kernel: [ 1352.390002] ide: failed opcode was: unknown

Nov 25 07:35:17 Tower kernel: [ 1352.390008] hdh: DMA disabled

Nov 25 07:35:17 Tower kernel: [ 1352.390034] pdc202xx_new: Secondary channel res

et.

Nov 25 07:35:17 Tower kernel: [ 1352.539687] ide3: reset: success

Nov 25 07:35:38 Tower kernel: [ 1373.099207] hdh: dma_timer_expiry: dma status =

= 0x41

Nov 25 07:35:48 Tower kernel: [ 1383.079554] hdh: DMA timeout error

Nov 25 07:35:48 Tower kernel: [ 1383.079566] hdh: dma timeout error: status=0x3a

{ DeviceFault SeekComplete DataRequest Index }

Nov 25 07:35:48 Tower kernel: [ 1383.079571] ide: failed opcode was: unknown

Nov 25 07:35:48 Tower kernel: [ 1383.079577] hdh: DMA disabled

Nov 25 07:35:48 Tower kernel: [ 1383.079603] pdc202xx_new: Secondary channel res

et.

Nov 25 07:35:48 Tower kernel: [ 1383.229256] ide3: reset: success

Nov 25 07:35:49 Tower kernel: [ 1384.658221] hdh: drive_cmd: status=0x30 { Devic

eFault SeekComplete }

Nov 25 07:35:49 Tower kernel: [ 1384.658229] ide: failed opcode was: 0xb0

Nov 25 07:36:19 Tower kernel: [ 1414.607471] hdh: lost interrupt

Nov 25 07:36:49 Tower kernel: [ 1444.548513] hdh: lost interrupt

Nov 25 07:37:19 Tower kernel: [ 1474.489555] hdh: lost interrupt

Nov 25 07:37:49 Tower kernel: [ 1504.430598] hdh: lost interrupt

Nov 25 07:38:19 Tower kernel: [ 1534.371639] hdh: lost interrupt

Nov 25 07:38:49 Tower kernel: [ 1564.312682] hdh: lost interrupt

Nov 25 07:39:19 Tower kernel: [ 1594.253724] hdh: lost interrupt

Nov 25 07:39:49 Tower kernel: [ 1624.194767] hdh: lost interrupt

Nov 25 07:40:19 Tower kernel: [ 1654.135809] hdh: lost interrupt

Nov 25 07:40:49 Tower kernel: [ 1684.076851] hdh: lost interrupt

Nov 25 07:41:19 Tower kernel: [ 1714.017892] hdh: lost interrupt

Nov 25 07:41:49 Tower kernel: [ 1743.958935] hdh: lost interrupt

Nov 25 07:42:19 Tower kernel: [ 1773.899977] hdh: lost interrupt

Nov 25 07:42:49 Tower kernel: [ 1803.841019] hdh: lost interrupt

Nov 25 07:43:19 Tower kernel: [ 1833.782061] hdh: lost interrupt

Nov 25 07:43:49 Tower kernel: [ 1863.723103] hdh: lost interrupt

Nov 25 07:44:19 Tower kernel: [ 1893.664146] hdh: lost interrupt

Nov 25 07:44:23 Tower init: Switching to runlevel: 0

 

 

After a while I gave up and switched off, hence the last line, I think. So is hdh dead? And if so, what happens if I replace it with a new hard disk when the last parity check was not completed? Will unRaid try to do the parity check first or will it try to replace hdh's contents?