I have an ABIT AB9 Pro, 2 1tb drives, 1 750gb drive and have not had any problems thus far.

 

My transfers keep slowing down and speeding up, my transfer rate was much faster with the older version of unraid, and idea's as to what the issue may be?

 

There are times when I am browsing a folder on the unraid box through a windows machine and the window closes, and the drives disappear from my network places. This problem worries me the most, but after 10-15 mins they all show back up.

 

Also can I pull out the HD's and run a diag on them on another computer without the risk of damaging data?

 

Last things please check over my syslog to see if there are any issues.

 

Thank you

 

Sorry don't know where else to host file

syslog.doc

My transfers keep slowing down and speeding up, my transfer rate was much faster with the older version of unraid, and idea's as to what the issue may be?

It helps others help you if you provide details, such as which versions of unRAID, and what the speeds are that you are seeing, and what kind of transfers were they (reads are very different from writes), and did it involve directly to or from a data disk, or to or from a User Share, and was a parity drive installed.  I can see from your syslog that you have a parity drive, and that you are running v4.4.2, but it helps to mention important details like that, for those who may not want to read the syslog.

 

There are times when I am browsing a folder on the unraid box through a windows machine and the window closes, and the drives disappear from my network places. This problem worries me the most, but after 10-15 mins they all show back up.

This sounds like a Windows problem, you need to give more detail such as what version of Windows.  Do the unRAID drives disappear from other machines on the network?

 

Also can I pull out the HD's and run a diag on them on another computer without the risk of damaging data?

Depends on what test you run.  Usually the test will clearly indicate whether it is non-destructive.  You of course do not want any test that writes to the disk.  If you aren't sure about a specific test, feel free to ask us.

 

Last things please check over my syslog to see if there are any issues.

Your syslog looks very good, with only one small hiccup at 6:39 AM on Jan 23, a frozen/timeout exception 5 seconds after the drive was issued a spin down command, which *is* significant, but which is not uncommon in SATA communications.  Apart from that, I don't see any issues at all.

My transfers keep slowing down and speeding up, my transfer rate was much faster with the older version of unraid, and idea's as to what the issue may be?

It helps others help you if you provide details, such as which versions of unRAID, and what the speeds are that you are seeing, and what kind of transfers were they (reads are very different from writes), and did it involve directly to or from a data disk, or to or from a User Share, and was a parity drive installed.  I can see from your syslog that you have a parity drive, and that you are running v4.4.2, but it helps to mention important details like that, for those who may not want to read the syslog.

 

There are times when I am browsing a folder on the unraid box through a windows machine and the window closes, and the drives disappear from my network places. This problem worries me the most, but after 10-15 mins they all show back up.

This sounds like a Windows problem, you need to give more detail such as what version of Windows.  Do the unRAID drives disappear from other machines on the network?

 

Also can I pull out the HD's and run a diag on them on another computer without the risk of damaging data?

Depends on what test you run.  Usually the test will clearly indicate whether it is non-destructive.  You of course do not want any test that writes to the disk.  If you aren't sure about a specific test, feel free to ask us.

 

Last things please check over my syslog to see if there are any issues.

Your syslog looks very good, with only one small hiccup at 6:39 AM on Jan 23, a frozen/timeout exception 5 seconds after the drive was issued a spin down command, which *is* significant, but which is not uncommon in SATA communications.  Apart from that, I don't see any issues at all.

 

Sorry sorry

 

Like you said I'm running version 4.4.2, the slow transfers are all writes, reads are fine. I transfer directly to the data disk and do not use user shares. I'm not sure on the exact speeds that I am getting, I will try to find some copying software that will tell me, but on version 4.3 the copy times were always constant and did not go up and down like they do in 4.4.2.

 

You are correct about the problem being windows xp related, they were showing up fine on my wired computer, and did not show up on my wireless. After a few minutes they showed back up onto the wireless computer.

 

Could that hiccup you mentioned have been caused by me when I tried to reboot the machine, since I need to spin down my drives before I do so?

 

Thanks for the quick reply RobJ!

Like you said I'm running version 4.4.2, the slow transfers are all writes, reads are fine. I transfer directly to the data disk and do not use user shares. I'm not sure on the exact speeds that I am getting, I will try to find some copying software that will tell me, but on version 4.3 the copy times were always constant and did not go up and down like they do in 4.4.2.

I'm not sure what size files you have tested with, but most of us are used to 'spiky' transfers to our unRAID servers, during gigabyte transfers.  On mine, I generally average about 9MB/s for writes, with highs almost 20MB/s and lows of zero, and about 25MB/s to 32MB/s for reads from the server.  If you are watching the speed (of a very large transfer), with very quick polling intervals, you may see the speed rise to somewhere in the twenties, then drop to zero for a bit.  This has always been normal for unRAID writes to parity protected drives.  I don't have any other advice to give, since there aren't any issues in your syslog.

 

Could that hiccup you mentioned have been caused by me when I tried to reboot the machine, since I need to spin down my drives before I do so?

No, when it happened, the server reset the drive and continued on without any further issues.  I have read (and this from people who should know) that SATA communications are somewhat fragile, more prone to these types of errors occasionally.  Not particularly encouraging, but I have found that they seem to be decreasing with each kernel release, so they are apparently successfully understanding and working around the weaknesses.  My own nForce 570 board has had absolutely NO issues since the update to the 2.6.27.7 kernel, and I had relatively numerous ones before.

I am having the exact same issues with 4.4.2 but with vista x 64 and an asus p5bvm do. I was getting faster writes to unraid and more stable speeds.

Is there a solution for this problem yet?  Write transfers from my XP box and my Vista box to the unraid server are suddenly hellishly slow, as in over an hour and a half for a 4.37 gig file.  Sometimes the file transfer bombs out entirely and the "copying file" status box just disappears without any error message... and without the file being copied.

 

Read file copies FROM the unraid server to both boxes are fine.

 

Copies from either Windows box to the other are fine, too.

 

The problem is strictly when copying TO the unraid server.

 

Also, my user shares (and disk13) have suddenly disappeared from my XP box's My Network Places (though oddly, they're still there in the Vista box's network).  I can still access those shares by typing the location into XP Windows Explorer's address bar.  But no matter how many times I refresh the My Network Places screen, the shares don't come back.  I'm having to use XP's "Add a network place" to get them back.

 

Any new ideas on what's up with all this?

 

Thanks!

 

 

Let me add to the above post that the unraid "Tower - Main" web page is showing no problems and no errors.

 

I recently replaced a 400gig sata drive with a 1tb sata drive (left the 1.5 jumper on because my mobo's sata connectors only do 1.5 anyway).  But these slow write speeds are occurring on ALL unraid drives, sata or ide.

 

I'm only copying to disk shares, not to user shares.

 

Unraid's NIC is a Netgear GA311 gigabit card, has never been an issue before.

 

Was still using unraid 4.0 when this issue suddenly appeared.  Upgrading to 4.4.2 did not help.

 

I don't have a cache drive (didn't know there was such a thing til I upgraded to 4.4.2).

 

Anything else I need to add?

 

Thanks!

 

 

Let me add to the above post that the unraid "Tower - Main" web page is showing no problems and no errors.

 

I recently replaced a 400gig sata drive with a 1tb sata drive (left the 1.5 jumper on because my mobo's sata connectors only do 1.5 anyway).  But these slow write speeds are occurring on ALL unraid drives, sata or ide.

 

I'm only copying to disk shares, not to user shares.

 

Unraid's NIC is a Netgear GA311 gigabit card, has never been an issue before.

 

Was still using unraid 4.0 when this issue suddenly appeared.  Upgrading to 4.4.2 did not help.

 

I don't have a cache drive (didn't know there was such a thing til I upgraded to 4.4.2).

 

Anything else I need to add?

 

Thanks!

 

 

The very first thing I would look at next the output of the

ifconfig eth0

command.  Look for any errors  or collisions on eth0 there.

 

Also, check the output of

ethtool eth0

Perhaps you are no longer connecting at 1000Mb/s speeds.

 

It could be as simple as a bad LAN cable, to as complicated as a bad port on your router or network card. (On the unRAID server)

Just because a network card worked before, does not mean it has not had a failure of some kind.  (Any lightning storms in your city these past months, or any static-cling in your house.)

 

If the degradation is coincident to the boot of a new release it might be a driver issue... Newer unRAID release sometimes contain newer Linux kernels and updated drivers. Perhaps one is buggy...

 

The "Tower" web-page will only show errors when a drive is unable to be written to.   The system log is a far better way of knowing if errors are occurring that affect performance, but do not prevent the data from being stored.

 

In any case, since 4.5-beta4 is out, and it is very stable... I'd try it.  If it was a driver issue, it might just be fixed. 

 

Joe L.

As Joe said, the syslog is very good for detailing what is going on with a poor performing drive or drives.  See my sig for the Troubleshooting link, for instructions in copying it.

 

There were some reports of slower performance with v4.4.2, perhaps because of NCQ settings.  There are more reports of significant *increases* in write performance with the latest betas.  I can say that either v4.5-beta3 or v4.5-beta4 have increased my write performance by roughly 50 % or more !!!  That is huge!  I've never been able to copy files this fast to my server, not even close.

Updated to 4.5 beta 4, no help.  An 8 gig file took nearly two hours to copy to the unraid box from my Vista box.  Rate never got above 1.2MB/sec.

 

Here's the syslog from this morning, after I upgraded to 4.5 beta 4 and rebooted.  I rebooted, copied the 8 gig file, and immediately made the syslog.

 

Thanks!

 

 

The syslog does not show any errors or serious performance issues.

 

It is important to see the results of the commands Joe suggested, to verify good network operation and configuration.

 

The next test I would suggest is to obtain SMART reports for ALL of the drives.  Installing UnMENU and checking the SMART view of the myMain plugin may be the easiest way to view SMART info for all of your drives.

 

Something I am curious about, but *may* not be a problem:  the syslog shows that the md unRAID module is still looking for another drive, at the position of hdj, which corresponds to your Disk 9, which is (or would be) located in the Slave position of the Primary cable on the second Promise card.  You indicated you saw no problems or errors on the Web Management page, and the syslog is NOT indicating a reconstruction of Disk 9, so I don't know why it is still looking for a missing IDE drive on hdj.  It must have existed at one time.  Does Disk 9 show as empty?

 

I do not know if any of the following is important or relevant, but thought I should at least mention it.  Your hardware base looks iffy to me, because the board appears to be based on a VIA 8237 chipset, or very similar to it.  The SATA drives are using the sata_via driver.  It's my recollection (perhaps faulty) that there are compatibility issues with the VIA chipsets.  You also are using 2 older Promise IDE controllers, and as I recall, there are issues with getting them to co-exist.  On the other hand, I think that problems with the Promise cards would show up as one card not starting at all, and according to the syslog, both of yours appear to install, set up, and work fine.  I can't help wondering though, if your performance issues are in any way related to the VIA chips.

 

Was still using unraid 4.0 when this issue suddenly appeared.

Just to clarify, are you saying that everything was fine while using v4.0, until suddenly performance dropped, WHILE STILL using v4.0?  That would seem to indicate a sudden hardware failure of some type.  Can you recall any changes made at that time, or just prior to that?

 

You asked earlier about a Disk 13 suddenly dropping out of an XP's networking list.  That sounds like a Windows networking issue, unfortunately not too uncommon to hear of, inconsistent behavior like that.  Usually, rebooting BOTH machines involved, once or twice, plus a little more time, takes care of it.  It won't provide a lot of confidence in your Window networking though!

One other test you can run is to copy that 8 gig file from one unRAID drive to another, with no network or other machine involved.  See the Transferring Files Within the unRAID Server wiki page for help with that.

The syslog does not show any errors or serious performance issues.

 

It is important to see the results of the commands Joe suggested, to verify good network operation and configuration.

Yes, it gives information not available elsewhere.

 

I'd like to see the contents of

config/disk.cfg

on the flash drive. 

If you log in via telnet, you can type

cat /boot/config/disk.cfg

Something I am curious about, but *may* not be a problem:  the syslog shows that the md unRAID module is still looking for another drive, at the position of hdj, which corresponds to your Disk 9, which is (or would be) located in the Slave position of the Primary cable on the second Promise card.  You indicated you saw no problems or errors on the Web Management page, and the syslog is NOT indicating a reconstruction of Disk 9, so I don't know why it is still looking for a missing IDE drive on hdj.  It must have existed at one time.  Does Disk 9 show as empty?

 

I have an empty slot in the middle of the assigned disks on my array, and my syslog does not complain about a device it cannot open, so I'm guessing your disk.cfg still lists something for that slot on that disk controller.

 

Joe L.

 

The syslog does not show any errors or serious performance issues.

 

It is important to see the results of the commands Joe suggested, to verify good network operation and configuration.

Yes, it gives information not available elsewhere.

 

I'd like to see the contents of

config/disk.cfg

on the flash drive.   

If you log in via telnet, you can type

cat /boot/config/disk.cfg

Something I am curious about, but *may* not be a problem:  the syslog shows that the md unRAID module is still looking for another drive, at the position of hdj, which corresponds to your Disk 9, which is (or would be) located in the Slave position of the Primary cable on the second Promise card.  You indicated you saw no problems or errors on the Web Management page, and the syslog is NOT indicating a reconstruction of Disk 9, so I don't know why it is still looking for a missing IDE drive on hdj.  It must have existed at one time.  Does Disk 9 show as empty?

 

I have an empty slot in the middle of the assigned disks on my array, and my syslog does not complain about a device it cannot open, so I'm guessing your disk.cfg still lists something for that slot on that disk controller.

 

Joe L.

 

 

The disk.cfg does indeed list a drive there, though the drive was showing the blue ball in tower-main, I copied the files to other drives, and removed the disk9 drive months ago.

 

Here's the disk.cfg in its entirety:

 

# Disk configuration

spindownDelay=0

parity=pci-0000:00:0f.0-scsi-1:0:0:0

disk1=pci-0000:00:0f.1-ide-0:1

disk2=pci-0000:00:0f.1-ide-1:0

disk3=pci-0000:00:0f.1-ide-1:1

disk4=pci-0000:00:0a.0-ide-0:0

disk5=pci-0000:00:0a.0-ide-0:1

disk6=pci-0000:00:0a.0-ide-1:0

disk7=pci-0000:00:0a.0-ide-1:1

disk8=pci-0000:00:0b.0-ide-0:0

disk9=pci-0000:00:0b.0-ide-0:1

disk10=pci-0000:00:0b.0-ide-1:0

disk11=pci-0000:00:0b.0-ide-1:1

disk12=pci-0000:00:0f.0-scsi-0:0:0:0

disk13=pci-0000:00:0f.1-ide-0:0

 

Tower-main correctly shows disk9 as "not installed."  Should I edit the disk9 line oir delete it, or what? 

 

BTW, I replaced the Netgear NIC with an Intel NIC today.  No difference.  Writes to the Unraid box still take forever and a day.

 

I'll see what I can do about those other commands you guys mentioned.

 

Thanks!

 

 

It is bad if the drive shows up as "blue" as that indicates the array still thinks the drive "should" be part of the array.  I really don't know if you have good parity protection... I think you do, but not really sure.

 

Is the parity drive indicator "green" or "orange"?  If orange, you are running in "degraded" mode... simulating the missing disk and not protected from a subsequent disk failure.

 

To get rid of the bogus entry, you probably need to stop the array, un-assign the disk (if it still is assigned on the devices page) then go back to the main page and press the button labeled "restore" to save a new configuration... without the un-installed drive.

 

Pressing "restore", followed by "Start" will start a full parity calculation, as "restore" throws away any existing parity data as it considers it to be a new configuration of disks where parity never was calculated previously.

It is bad if the drive shows up as "blue" as that indicates the array still thinks the drive "should" be part of the array.   I really don't know if you have good parity protection... I think you do, but not really sure.

 

Is the parity drive indicator "green" or "orange"?  If orange, you are running in "degraded" mode... simulating the missing disk and not protected from a subsequent disk failure.

 

To get rid of the bogus entry, you probably need to stop the array, un-assign the disk (if it still is assigned on the devices page) then go back to the main page and press the button labeled "restore" to save a new configuration... without the un-installed drive.

 

Pressing "restore", followed by "Start" will start a full parity calculation, as "restore" throws away any existing parity data as it considers it to be a new configuration of disks where parity never was calculated previously.

 

Disk9 was showing blue until I disconnected it, at which point it showed grey and "not installed." 

 

I went into Devices and unassigned it (wasn't aware I needed to do this til now).

 

Did another file write to the Unraid box, still only 1.5MB/sec, though I didn't see your line above about doing a restore yet.

 

Now I'm doing a restore with Disk9 unassigned.  Gonna take a while.

 

BTW, parity disk has shown green throughout all this until I started the restore just now.

 

I'll let y'all know how it goes. 

 

Thanks!

 

 

Did you ever get the output of the two commands I requested?

 

ifconfig eth0

and

ethtool eth0

 

 

Yup, didn't really see anything that would seem (to me) out of the ordinary..

 

RX errors 0, dropped 0, overruns 0, frame 0

 

TX errors 0, dropped 0, overruns 0, carrier 0

 

collisions 0, txqueuelen 1000 <-- admittedly I don't know what this last one is.

 

ethtool showed 1000 speed, autonegotiating on, nothing that seemed unusual to me.

 

 

Sl;ightly off topic, what's a typical speed for a parity sync to run?  Mine is doing about 1980 KB/sec, which is about the same speed as writes to the Unraid over the network.

 

Is this good or bad?  Slow?  Typical?

 

Thanks!

 

 

Sl;ightly off topic, what's a typical speed for a parity sync to run?  Mine is doing about 1980 KB/sec, which is about the same speed as writes to the Unraid over the network.

 

Is this good or bad?  Slow?  Typical?

 

Thanks!

 

 

See here: http://lime-technology.com/wiki/index.php/User_Benchmarks

 

Slowest on an old PCI bus based Mostly IDE array with 15 drives is 11MB/s. SATA array with 14 drives seems to be 44MB/s. (nearly 4 times faster)

Fastest is an array with only 3 SATA drives at 95MB/s.

 

I'd say you are about 10 times slower than expected.

 

Joe L.

 

 

Well in that case I'd say I wasn't so off topic after all.  I'll bet my slow parity sync is caused by the same issue that's causing my slow writes in the first place.

 

Wonder what would happen if I shut down, removed the parity drive temporarily, and rebooted?

 

 

Well in that case I'd say I wasn't so off topic after all.  I'll bet my slow parity sync is caused by the same issue that's causing my slow writes in the first place.

 

Wonder what would happen if I shut down, removed the parity drive temporarily, and rebooted?

 

 

If you just removed the parity drive it would be exactly as if it failed.  When you put it back parity would need to be re-calculated.

 

You should be able to just un-assign it and re-start the array.

 

Did you ever tell us the make/model of your motherboard and disk controllers?  Obviously, it is mostly IDE based (much like mine) with a few SATA drives but a look at the BIOS options might be in order.

 

There were options on early BIOS to use SATA drives as emulated IDE drives... (as in a very slow emulation)  Perhaps your BIOS has such an option?