All-

At first my UnRAID was working great, but then I added 2 PATA drives to it, and it has been unbelievably slow. In fact, sometimes the shares will disapear altogether from the network, often when I'm 1/3rd of the way into a DVD backup. I'd really like to know why. MY Mainboard is a DFI Lanparty NFII (Athalon XP 2500), and my drives are a combination of SATA (Samsung 750 HD753LJs and  Western Digital WD7500AAKS) and PATA (older Segate 250s). I'm using 1 Promise SATA300 TX4 and 1 RocketRAID 1520 SATA 2 Channel for SATA control, Manboard IDE for the PATA drives.

 

I'm using the onboard gigabit NIC.

 

My log file is attached in 2 parts here and below.

 

Thanks in advance for everyone's help!

Log file pt. 2

The way you have the 2 PATA drives attached, each to a separate IDE channel onboard, is the preferred way.  Unfortunately, something went wrong with the Secondary IDE channel at 10:02pm, an hour and a quarter after the drive had been cleared and formatted, and that channel was shut down.  You could try moving that drive onto the Slave position of the Primary channel, since no errors were reported about it.  You will probably have to adjust the jumper on it.  It does not appear to be a drive problem, but a motherboard problem.

 

There is no indication of network problems.

 

The syslog does recommend using the irqpoll parameter.  If moving the drive to the other channel does not seem to be working well either, you might edit the syslinux.cfg file in the root folder of your unRAID flash, and add a space and irqpoll to the end of the line that begins with append, and reboot.

 

OK, It's about an 70 min from finishing a parity build. When it's done, I'll try moving everything to the primary IDE channel. What does the irqpoll parameter do?

Update:

I tried moving everything to the Primary IDE channel, and then copying a few DVD backups to the server. After about 20 minutes, the server hangs hard- I have to do a hard reboot, which of course means no log from the UnRAID server. however, 15 min before the crash is the last entry in the PuTTY tail I was running:

 

May  2 23:16:39 Server kernel: [  238.104645] spurious 8259A interrupt: IRQ7.

 

I've gone ahead and entered in irqpoll, so that didn't seem to help. I also tried swapping IDE cables, just in case.

Update:

I tried moving everything to the Primary IDE channel, and then copying a few DVD backups to the server. After about 20 minutes, the server hangs hard- I have to do a hard reboot, which of course means no log from the UnRAID server. however, 15 min before the crash is the last entry in the PuTTY tail I was running:

 

May  2 23:16:39 Server kernel: [  238.104645] spurious 8259A interrupt: IRQ7.

 

I've gone ahead and entered in irqpoll, so that didn't seem to help. I also tried swapping IDE cables, just in case.

Try nolapic noapic instead or irqpoll.  They seems to help many people. If nothing else, they can be removed if they do not help.

 

append initrd=bzroot rootdelay=10 nolapic noapic

 

Joe L.

Update:

at 8:30 this morning (according to the log) myUnRAID server choked again. Interestingly, it was about 4 hours after completing a 60GB copy operation. I replaced the irqpoll with nolapic noapic this morning, and have so far backed up another 80GB of DVDs while playing a BD backup without issue. I'll report back either a) in 48 hrs or b) after the next crash - whichever comes first.

And tragically, I'm back.

 

after backing up a good 100GB of DVDs today, while my wife was streaming previously backed up DVDs (also from the UnRAID server) on another computer, The sever completely hung about 15% of the way into a backup. Interestingly, this was even after taking a break from backing up to go see Iron Man.

 

I think this may be completely unrelated to the earlier PATA issue, as the only issue now seems to be stability - when it's up, performance is just fine.

 

Annoyingly, there's nothing in the log I was collecting thru a telnet session- the last items are from this morning, after I canceled a parity check:

 

May  3 10:26:27 Server kernel: can't shrink filesystem on-line
May  3 10:26:27 Server last message repeated 2 times
May  3 10:26:28 Server kernel: ReiserFS: md4: replayed 7 transactions in 1 seconds
May  3 10:26:28 Server kernel: ReiserFS: md4: Using r5 hash to sort names
May  3 10:26:28 Server kernel: can't shrink filesystem on-line
May  3 10:26:34 Server kernel: usb 2-1: USB disconnect, address 2
May  3 10:26:34 Server kernel: usb 2-1.1: USB disconnect, address 4
May  3 10:26:34 Server kernel: usb 2-1.2: USB disconnect, address 5
May  3 10:26:41 Server in.telnetd[1832]: connect from 192.168.1.150 (192.168.1.150)
May  3 10:26:44 Server login[1833]: ROOT LOGIN  on `pts/0' from `192.168.1.150'
May  3 10:27:36 Server kernel: ReiserFS: md12: replayed 132 transactions in 69 seconds
May  3 10:27:36 Server kernel: ReiserFS: md12: Using r5 hash to sort names
May  3 10:27:36 Server kernel: can't shrink filesystem on-line
May  3 10:28:27 Server kernel: spurious 8259A interrupt: IRQ15.
May  3 10:29:48 Server kernel: ReiserFS: md14: replayed 342 transactions in 201 seconds
May  3 10:29:49 Server kernel: ReiserFS: md14: Using r5 hash to sort names
May  3 10:29:49 Server kernel: can't shrink filesystem on-line
May  3 10:29:50 Server emhttp: shcmd (18): mkdir -m 700 /mnt/user
May  3 10:29:50 Server emhttp: shcmd (19): /usr/local/sbin/shfs /mnt/user
May  3 10:29:51 Server emhttp: shcmd (20): killall -HUP smbd
May  3 10:30:05 Server kernel: mdcmd (19): nocheck
May  3 10:30:05 Server kernel: md: md_do_sync() got signal, exit...
May  3 10:30:05 Server kernel: md: recovery thread sync completion status: -4

 

So that's the last line before the sudden death tonight. Does using tail -f /var/sys/syslog capture all the same information as grabbing the syslog from the server itself?

 

spurious 8259A interrupt: IRQ7

spurious 8259A interrupt: IRQ15

 

Spurious IRQ's aren't a good thing, but they are generally harmless, if the IRQ is not in use.  In this case, IRQ15 would be the second IDE channel again, which you stopped using.

 

I have to say that it may be your motherboard.  I don't recommend any nForce board older than the nForce 5 series, nForce 500, nForce 570, and nForce 590, and up.  I had disastrous results with an nForce 4 board, and although not the same as your nForce 2, I recall comments, while researching all of the problems people were having with the nForce 4 series, that some of the problems had also been in the earlier nForce 2 and nForce 3 boards.

 

Yeah, I was quietly wondering that as well. Just for the heck of it, I tried moving the one Samsung 750 HD753LJs from the Promise SATA300 TX4 to the 1 RocketRAID 1520 SATA 2 Channel, as it seems like a few folks have had issues with HD753LJs and TX4s. No such luck- it dies on the very same back up to the very same drive (the HD753LJ). So, will I be able to carry my array to a new mainboard?

So, will I be able to carry my array to a new mainboard?

Absolutely.  All you need to do is assign the same physical disks to the same logical slots if the new motherboard assigns sd_ devices in a different order.

Most important is the parity drive.  The others don't matter as much, other than if you swap them around what used to be at /tower/disk1 might end up on /tower/disk3.

 

So, use the print button on your browser to record what the disks/serials numbers are now, and then put them back when you get the motherboard swapped.

 

Other than that, you do not need to change anything on the flash drive, or anything on the disks themselves.  This is one huge advantage of unRAID over some hardware based RAID solutions.  For the most part, the hardware does not matter. (as long as it is supported and has drivers for its chipsets)

 

Joe L.