I've been noticing some really slow write speeds when copying files from my Win 7 desktop to my unRAID server disk share.  I am copying a 981 MB file and Winodws reports an avg of 900 KB/s.  I timed it took 18 minutes and 30 seconds which comes out to 1.13 MB/s by my math.  Both computers are using Gbe at full duplex according to Device Manager for the Win desktop and ethtool for the unRaid server.  Ping time is <1 ms. between the two computers.  Both drives are SATA II and connected to the SATA ports on the mobo.  The mobo is a MSI P43 Neo3-F with 3 Gb/s SATA ports.  I've changed cables to rule them out and the results are the same.  When I try writing the same file to other disks on the server I get 5-6 MB/s.  I'm not an expert on this stuff, but isn't that still slow even with parity?

 

I've attached the syslog and SMART reports for both drives below.  Does anyone see anything that could be causing this?  What kind of speeds should I be seeing?

 

EDIT: AHCI is enabled in BIOS.

ParitySMART.txt

Disk1SMART.txt

Syslog.txt

I'm getting similar speeds when transferring that file from another drive on the server via Midnight Commander.  Although, I did that via a telnet session from my Win 7 desktop.  That would still rule out a network problem right?

I'm getting similar speeds when transferring that file from another drive on the server via Midnight Commander.  Although, I did that via a telnet session from my Win 7 desktop.  That would still rule out a network problem right?

It should.

Parity is showing problems:

197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3

 

Rebuilding parity may help:

1. Stop the array and un-assign parity.

2. Start the array then stop the array. (Tis causes unRAID to "forget" about the parity disk.)

3. Assign parity and start the array.

 

Parity will rebuild.

I thought that was only a problem if it kept happening.  I'll rebuild parity when I get a chance.  That wouldn't cause slow write speeds would it (especially to only one drive)?

It depends on where on the disk the files resides. And 5-6MBps is very slow. It should be over 30.

That's where I get confused.  If I keep moving the file around to different drives, doesn't it's location change?  Also, I have copied other similarly sized files to the server and I get the same speeds.

It looks like you have quite a few older drives in your array.

 

That Samsung 400GB for example is a very slow performer by todays standards. That would be a suspect for slow writes to that drive.

 

http://www.harddrivebenchmark.net/hdd.php?hdd=SAMSUNG+HD400LJ

 

When people are saying you should see 30MB/s+. we are assuming you have current models.

Try and limit your your testing to your best drives.

 

also, your parity drive should not only the largest drive, but it helps if it is the fastest drive you have. It will always be the deciding link on the array for maximum write speed. a slow parity drive will slow all writes.

 

But, I will agree that 5-6MB/s is still a little slow. I feel something is not quite right.

Yah, I know I have old drives in there.  I think some are even SATA I.  I don't need top notch performance as it's only a media server, but what I'm getting seems really slow.  Don't forget that while we all seem to agree that 5-6 MB/s is slow the drive I initially posted about is only getting ~1 MB/s.  I see a lot of "configured for UDMA/133" in the syslog.  What is that about?  I find it hard to read the log in terms of telling if drives are configured for SATA I or II?  Also, was there something in the log that told you the Samsung drive is pretty slow or are you just familiar with that drive?

Parity is showing problems:

197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3

 

Rebuilding parity may help:

1. Stop the array and un-assign parity.

2. Start the array then stop the array. (Tis causes unRAID to "forget" about the parity disk.)

3. Assign parity and start the array.

 

Parity will rebuild.

 

I just start a parity rebuild.  Just curious, how does that help with the pending sectors?

When a pending sector is written one of two things will happen. If the write is successful, the the pending count goes down and this is the desired effect. If the write is not successful, the reallocated count will rise and the pending count will decrease. An unsuccessful write means that you will have to watch the SMART reports for this disk to see if the pending and/or reallocated counts continue to rise. If the counts remain stable the disk should be ok and if not then disk is failing and should be replaced ASAP.

OK.  I performed a parity rebuild and man it was slow (~33 hrs for my 6.7 TB array), but it found no errors.  The parity drive's pending sectors count did increase by one though.  Writes are still very slow.  In fact the last few times I tried to write a large file, after a few minutes Windows gives me an error saying, "There is a problem accessing \\tower1\disk1\. Make sure you are connected to the network and try again.".  I've tried to copy the same file to a couple other disks on the server and the same thing keeps happening.  I'm basically unable to write anything even remotely large to my server now.  The WebGUI takes a long time to load pages.  Sometimes a minute or two.  That's not new since the parity rebuild, but has been going on for a little while now.

 

I'm really at a loss now and I have no clue where to go from here.  Is the parity drive toast with 4 pending sectors and 0 reallocated sectors?  It syas it passed the SMART test.  Is the mobo going bad?  The server didn't use to be like this and I haven't added anything new to it in quite some time.

 

I've attached a new SMART report for parity and Disk1 along with a syslog.

SMART_Disk1.txt

SMART_Parity.txt

Syslog.txt

I also noticed this:

 

root@Tower2:~# hdparm -tT /dev/sda

 

/dev/sda:

Timing cached reads:  2452 MB in  2.00 seconds = 1226.68 MB/sec

Timing buffered disk reads:  242 MB in  3.02 seconds =  80.07 MB/sec

root@Tower2:~# hdparm -tT /dev/sdb

 

/dev/sdb:

Timing cached reads:  1910 MB in  2.00 seconds = 954.97 MB/sec

Timing buffered disk reads:  128 MB in  3.01 seconds =  42.55 MB/sec

root@Tower2:~# hdparm -tT /dev/sdc

 

/dev/sdc:

Timing cached reads:  1584 MB in  2.00 seconds = 791.74 MB/sec

Timing buffered disk reads:  212 MB in  3.01 seconds =  70.49 MB/sec

root@Tower2:~# hdparm -tT /dev/sde

 

/dev/sde:

Timing cached reads:  2592 MB in  2.00 seconds = 1296.71 MB/sec

Timing buffered disk reads:  288 MB in  3.00 seconds =  95.85 MB/sec

root@Tower2:~# hdparm -tT /dev/sdf

 

/dev/sdf:

Timing cached reads:  1664 MB in  2.00 seconds = 831.72 MB/sec

Timing buffered disk reads:    6 MB in 13.56 seconds = 453.01 kB/sec

root@Tower2:~# hdparm -tT /dev/sdg

 

/dev/sdg:

Timing cached reads:  2566 MB in  2.00 seconds = 1282.91 MB/sec

Timing buffered disk reads:  370 MB in  3.01 seconds = 122.78 MB/sec

root@Tower2:~# hdparm -tT /dev/sdh

 

/dev/sdh:

Timing cached reads:  2558 MB in  2.00 seconds = 1278.96 MB/sec

Timing buffered disk reads:  210 MB in  3.00 seconds =  69.93 MB/sec

root@Tower2:~# hdparm -tT /dev/sdi

 

/dev/sdi:

Timing cached reads:  2628 MB in  2.00 seconds = 1314.38 MB/sec

Timing buffered disk reads:  226 MB in  3.02 seconds =  74.73 MB/sec

root@Tower2:~# hdparm -tT /dev/sdj

 

/dev/sdj:

Timing cached reads:  2606 MB in  2.00 seconds = 1303.04 MB/sec

Timing buffered disk reads:  226 MB in  3.01 seconds =  75.05 MB/sec

 

sdf is my parity drive.  I'm assuming that I can take it from all this that my parity drive is dying?

This could be a power issue. What type is PSU?

 

Do disk 1 and parity share a power splitter? Do they share a PCIe SATA card?

Here is my PSU: http://www.antec.com/specs/SP500_spe.html

 

The drives do not share a power splitter, but they are on the same cord.  Both drives are connected to the onboard SATA.

That PSU has multiple 12V rails. Only one of them is used for the disks and MB. It could be the cause of these problems. See here: http://lime-technology.com/forum/index.php?topic=12219.0

Any way to check? I hate to put money into a new PSU and find out that doesn't fix it. The dual rails didnt seem to be a problem before, and I haven't changed anything in 6-8 months.

Two drives now have 4 pending sectors and they have nothing else in common; so this points to the PSU. 9 drives use at least 18 amps. That leaves nothing for the MB. Read the Power Supply Thread and decide for yourself. Keep in mind that it's only using one of the 12V rails. That PSU only provides 17 amps of power.

I'll check it out. Thanks for your help!

I just received an email from the server that unRaid just red balled my parity drive showing 768 errors.  I can't get a SMART report now either:

 

Device: /5:0:0:0  Version: 
scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options..

All of these problems can be caused by an insufficient PSU.

What do you think about swapping it with this one as a test?  I know it's a cheap no name, but it's a single rail and has more amps. I have one of these in a desktop I could pull to test.

 

http://www.newegg.com/Product/Product.aspx?Item=N82E16817170017

 

 

That should be better. Is 25A over the budget?

That one is 25 amp, right?

Yes. It's 25 amps. 5A for the MB + 2A per green drive + 3A per non-green drive = total required.