So the long a the short of this is I was having trouble with a 1.5 tb seagate and it was causing slow write speeds, once I switched over to 4.4.2 (it was only 1 of 3 1.5tb drives in my system was acting up). I purchased 2 new 1.5 tb drives with one of them going to be used to replace that old drive that was acting up. But before I could replace the problematic drive my parity drive started spitting out errors. I decided to replace that first, but while rebuilding parity the speedswere terrible 500KB/sec. So i thought this might be from the seagate drive freezing. So I backed up all the data on the 1.5 tb drive that was causing me trouble and and then removed it from the array. I then used the dreaded restore option, since I knew that all the data on the other  drives was fine and needed to create a whole new parity. at first the speeds were fine, like 50,000-60,000 KB/sec but now when I woke up the speeds are down to 2500-12000 KB/sec. I checked my syslog and it showing an error, but I don't know what it means. Thank you for any help that you can provide. Syslog attached below.

 

ps it wont let me attach anything as an attachment so for right now here is the repeat error i get in my syslog

 

Feb 7 06:43:45 Tower kernel: ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x4850002 action 0xe frozen

Feb 7 06:43:45 Tower kernel: ata3: SError: { RecovComm PHYRdyChg CommWake LinkSeq DevExch }

Feb 7 06:43:45 Tower kernel: ata3.00: cmd 35/00:80:7f:34:28/00:02:09:00:00/e0 tag 0 dma 327680 out

Feb 7 06:43:45 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x14 (ATA bus error)

Feb 7 06:43:45 Tower kernel: ata3.00: status: { DRDY }

Feb 7 06:43:45 Tower kernel: ata3: hard resetting link

Feb 7 06:43:46 Tower kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

 

 

here is the link to the full syslog - http://www.mediafire.com/?sharekey=91c54c55c4c664904012e8015643d9c8e98b60d2eaee7f4d

Here's the line that is mostly responsible for shafting your speed:

Feb 7 03:59:12 Tower kernel: ata3.00: limiting speed to UDMA/33:PIO4

Because of all of the repeating exceptions (ATA bus error), you had previously been slowed to UDMA/100 and SATA 1.5Gbps.  This of course hugely impacted your speed, but what was also slowing things down was the errors themselves, because they cause a hard reset of both drives on the 'channel', and that seems to stop everything for 2 to 5 seconds, each reset.

 

Number one suspect would be the SATA cable to your new parity drive.  And if you had been using it before, it may have been responsible for your previous drive errors, on whatever drive was attached to it.  The next suspect would be the port that it is connected to, and you do have some unused ports to try instead.  I don't think there is a problem with the drive, but a SMART test would help rule that out, see the Troubleshooting page, Obtaining a SMART report section.

 

I don't know if I should mention the following, because it does not appear to have been a real problem, no apparent harm found.  But it does bother me, as very unusual behavior, probably wrong behavior.  Perhaps Tom should be aware of it.  I found the following lines in your syslog, immediately after you clicked the Restore button, and just before clicking the Start button.

Feb 7 03:38:42 Tower emhttp: writing mbr on disk 5 (/dev/sdf)

Feb 7 03:38:42 Tower emhttp: re-reading /dev/sdf partition table

Feb 7 03:38:42 Tower kernel: sd 5:0:0:0: [sdf] 2930277168 512-byte hardware sectors (1500302 MB)

Feb 7 03:38:42 Tower kernel: sd 5:0:0:0: [sdf] Write Protect is off

Feb 7 03:38:42 Tower kernel: sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00

Feb 7 03:38:42 Tower kernel: sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Feb 7 03:38:42 Tower kernel: sdf: sdf1

 

Disk 5 is one of your existing good data drives, was not involved in any of the problems, and was not shuffled around or moved in any way, so I can't see any reason for this.  Writing the drive's MBR is only done just before or after Clearing the drive, before it is formatted, and should normally never need to be done again, at least in an unRAID environment.  I assume in this case it just wrote what was already there, because it did not proceed to format the drive.  It mounted it as usual, and found a ReiserFS with no issues, and had no problems checking its transaction log.

I will be making the necessary adjustments tonight. I did get the parity sync to complete, and then added another drive and it formatted properly, but then again with the new parity drive I was getting errors. I think you may be right about the cables, so I have to add some ram to the computer tonight and I will double check all the connecitons. Thanks!