>3 MB Transfers?

Been using unRAID for the past week and has been working great. Today though, I added a 4th drive (5th if you count the parity) and all of a sudden I went from 25-30 MB transfer speeds down to 3 MB or less. I tried writing to the new drive and one of the drives that was already there and they both get these horrible transfer speeds. I also have taken the 4th drive out of the array and still slow horrible transfer speeds. Any ideas?

No.

 

Post your syslog.

You know, I think the drive never removed from the array. I removed it under devices but the main page shows it there but a missing. How can you remove it from the array?

Post a syslog.

 

I will but I want to make sure on how to remove this drive from the array. I wan to see if that is the cause of the problem.

syslog attached.

syslog.txt

I will but I first want to make sure on how to remove this drive form the aray.

Un-assigning a drive is treated exactly the same as if the drive has failed.  The parity disk in combination with all the other data disks will simulate the "missing" disk.

 

To remove a disk from the array you must initialize a new disk configuration.  This will immediately invalidate the parity calculations based on the prior disk configuration.  When you next start the array, a full initial parity calculation will then occur.

 

To initialize a new disk configuration do the following:

 

1. Stop the array by pressing "Stop" on the web-management console.

2. Go to the "devices" page and un-assign any disk you wish to un-assign.

3. Log in on the system console, of via telnet as "root"

4. Type

initconfig

Respond to its prompt with "Yes"

(Exactly as typed... Capital "Y" lower case "es")

5. On the web-management page, return to the main page, all indicators should be "Blue"  (if already there, refresh the page)

6. Press "Start" to begin a new parity calculation based on the new configuration of disks and start the array.

Gotcha. Well I may until bedtime to do that. So does the log show anything that can point out the cause of the slowness? I did have this drive in the array before with 3 drives, but had pulled it to replace it with another drive. Never had slowness until now and what seems when I added it as the 4th drive.

So i went ahead and did that but still, getting terrible transfer rates. I wonder if possibly I have a bad network cable or something. Will try to mess around with my hardware for a bit.

Nothing seems obvious in the syslog you posted, other than using a Samsung HD204UI drive. Despite it's performance issues, I don't think it would be that severe. For more info on the Samsung issues, see this thread: http://lime-technology.com/forum/index.php?topic=8012.0

 

These drives are connected and detected:

pci-0000:00:1f.2-scsi-0:0:0:0 host1 (sda) SAMSUNG_HD204UI_S2HGJ1BZ835455

pci-0000:00:1f.2-scsi-2:0:0:0 host3 (sdb) ST31500341AS_9VS08VQ4

pci-0000:00:1f.2-scsi-3:0:0:0 host4 (sdc) SAMSUNG_HD103SI_S210JDWSB20772

pci-0000:00:1f.2-scsi-4:0:0:0 host5 (sdd) ST31500341AS_9VS1GGHV

 

These drives are in the array:

parity: md: import disk0: [8,0] (sda) SAMSUNG HD204UI  S2HGJ1BZ835455

disk 1: md: import disk1: [8,16] (sdb) ST31500341AS    9VS08VQ4

disk 2: md: import disk2: [8,32] (sdc) SAMSUNG HD103SI  S210JDWSB20772

 

If I understand what you're saying, you removed disk 3, (sdd) ST31500341AS_9VS1GGHV, from the array and still suffer performance issues.

Oct  8 17:12:45 PhenixHomeServ kernel: md: disk3 missing

 

To be certain, make sure you're not writing to a simulated disk 3 if you haven't removed it from your system using the steps Joe L outlined when doing your tasks.

 

I don't know if this is normal, but there's several messages about the network link being up. To me it would seem normal to only see the "eth0 link up" once, but if your network is going up and down, there should also be a "eth0 link down" message or two.

Oct  8 17:12:44 PhenixHomeServ kernel: r8169: eth0: link up

Oct  8 17:12:44 PhenixHomeServ kernel: r8169: eth0: link up

Oct  8 17:12:44 PhenixHomeServ ifplugd(eth0)[1371]: Executing '/etc/ifplugd/ifplugd.action eth0 up'.

Oct  8 17:12:44 PhenixHomeServ ifplugd(eth0)[1371]: client: Polling for DHCP server on interface eth0:

Oct  8 17:12:45 PhenixHomeServ logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -d -t 30 -h PhenixHomeServ eth0

Oct  8 17:12:45 PhenixHomeServ kernel: r8169: eth0: link up

Oct  8 17:12:45 PhenixHomeServ ifplugd(eth0)[1371]: client: dhcpcd: MAC address = 00:1f:d0:d4:a2:41

Oct  8 17:12:45 PhenixHomeServ ifplugd(eth0)[1371]: client: dhcpcd: your IP address = 10.0.0.3

Oct  8 17:12:45 PhenixHomeServ ifplugd(eth0)[1371]: client: dhcpcd: MAC address = 00:1f:d0:d4:a2:41

Oct  8 17:12:45 PhenixHomeServ ifplugd(eth0)[1371]: client: dhcpcd: your IP address = 10.0.0.3

Well I saw this issue happen with all the drives in the array and after. I'll read more about the link you posted on the Samsungs but I did notice when I took out the parity drive, transfers seem to be normal. I am going to add it back in once I finish copying some files and see what happens.

I don't know, using the HD204 as the parity drive could result in very low speeds.  It just depends on what you are transferring.  I've come to the conclusion that on network transfers (where even large sequential files are broken down into packets), you never get the full sequential transfer speeds.

 

It's also been my experience, that when you perform a write, the effective transfer rate is 1/3 to 1/4th the speed of the slowest drive (in my system it is almost always 1/3).  Having the HD204 as your parity drive is probably the worst possible scenario, as your write speeds could effectively be cut 50%, and the also loose the unRAID overhead on top of that.  

 

I think you are looking at a scenario where your actual write speed could be very low.  3MB/s would be lower than I would expect for something like a DVD rip, but if you were transferring a number of JPEG files (100 files @ 2Mb each), then  I could easily see your speed being around 5 MB/s or worse.

Odd. I put it back in and all seems fine again. Hm...I wonder if it is because I was copying from my HTPC and was recording a few shows at the same time, but...I also was copying form a drive that wasn't recording TV too. I'll keep an eye on this.

Maybe I spoke too soon. As soon as I turned on a parity check the transfers dropped like a rock. Then I stopped the parity check, they still stayed pretty badly. When I took the drive from parity again, it took awhile for transfer speeds to go back up but they are normal again. So maybe it is because it's a Samsung. I did read over the other thread but I don't really understand what it all says, besides that Samsungs have issues. I am also testing by transferring DVD and Blu-ray ISOs which according to the other thread those should be okay but I am seeing these poor transfer rates.

So I replaced this Samsung as the parity with a Seagate and it seems to be working normally. So I guess like in the other post, Samsungs should be used as a parity. I think I am going to order a 2 TB Seagate and just use the 2 TB Samsung as a data drive, as the other Samsungs as data drives seem to be okay.

Still see the same issue with the Samsung taken out. I added a 4rd data drive and this time it is also a Seagate and I am just getting these horrible transfer speeds. I haven't added the other Seagate as a parity drive as it is doing a preclear. It also is slow no matter which drive I write to. I don't get it.

Here is an updated syslog.

syslog.txt