******

This question has been solved (thanks again to Joe).

The issues described below were caused by a combination of bad RAM, a split-level that was one-folder too high in the tree and an unRAID disk that was around 90% full. By my observations, when a drag-and-drop copy in Mac OS 10.5 takes "too long" you'll get an "error -51". Hopefully this will help someone else in the future.

 

Thanks, Joe.

******

 

I've been chasing this for a week or so now and have made no progress by myself.

 

Issue:

I am unable to copy large files to my unRaid server (using drag & drop from an OS X client machine).

 

Additional information:

I'm not sure what the cutoff size is because I haven't tested with anything between a 300 KB and 1.5 GB. I can copy small files just fine (I've tried several < 300 KB) but when I try to copy a large file (> 1.5 GB) it starts off quick as normal but then the transfer slows down when it reaches 70-80MB. It eventually grinds to a halt after 100 MB or so. On my Mac, I get "Error -51" (which translates to "Error in user parameter list" for OS 9 - not sure it means the same thing in OS 10.5).

 

Recent Changes (since it was working):

- Replaced some cabling in my server closet. It all toned out correctly and I seem to have no other issues with other servers using the same new cabling (i.e. I've switched them around but the problem doesn't move).

- Started accessing one of my unRaid shares from a MythTV (Ubuntu) server. This is where I suspect I did something to fowl it up. While setting it up I was having problems with permissions to the share. I made some changes to the Samba config files on the unRaid box but these had no affect so I changed them back. There's a chance I failed to revert everything I changed so any advice in how which files should look would really be appreciated here.

 

Observations:

- Doesn't matter what file I try. Any big file (> 1.5 GB) fails regardless of the format. Any small file (random document, PDF, etc.) succeeds.

- Parity check is WAY slower than it used to be. The one I did yesterday averaged 19 M/sec. The one I did before that (prior to this issue) averaged over 40 M/sec.

- Using FTP I can successfully copy a large file. However it does take a lot longer than it used to.

- When I access a share using FTP, I cannot list the contents. I can get and put just fine. I just can't see what's there using FTP.

- Reading from the unRaid server is as fast as it ever was.

- Disk space is not a problem. I have a 3-disk system (1 is parity). There is over 400 GB free - split evenly between disk1 and disk2.

- I get the error when copying to a user share or to a folder on "disk1" or "disk2"

- Doesn't matter what user share I try. I get the same error with all of them.

- When I get this error, nothing shows up in the syslog (at least I think so. I've attached a copy here if you want to look at it).

 

Things I've tried so far:

- SMART test (both short & long) on all drives - nothing out of the ordinary

- File System check - no errors

- Parity check - no errors (but as I already mentioned, it took over twice as long as it normally does).

- Verified good cabling between client & unRaid machine (I replaced cables on both client and server with some known to work before. I even replace the patch cables).

- Created a new user share but I get the same error with that one too.

- Turned off unmenu and all the packages I use.

 

Sorry for the long post. Hoping something in there might help diagnosis. I think I just need another set of eyes to look at this.

 

Thanks,

Kyle

syslog-2010-02-23.txt

After the above post, I discovered some memory errors so I replaced the RAM in my unRAID server.

 

After installing:

• Ran memtest for about 48 hours (no errors)
  
• Ran reiserfsck on each data volume (no errors)
  
• Ran parity check on the array (no errors)
  

 

It seems the problem is only better, not gone. I can copy 2GB plus files to the server, but if I try to copy a group of files (say about 10 GB worth) then I eventually get the same error as before. Still nothing showing up in the syslog.

 

Any ideas? I really want to trust this NAS but it's getting harder.

 

Please help. Even if you only have an idea - please help.

Here's another weird observation.

 

Right now, disk2 has more free space on it than disk1. I have the allocation method set to "most free" so the first file I copy to that share should go to disk 2, right? Wrong. Regardless of how much free space there is on disk2, the files I copy to the user share, get copied to disk1.

 

Maybe that will help someone get me pointed in the right direction???

Here's another weird observation.

 

Right now, disk2 has more free space on it than disk1. I have the allocation method set to "most free" so the first file I copy to that share should go to disk 2, right? Wrong. Regardless of how much free space there is on disk2, the files I copy to the user share, get copied to disk1.

 

Maybe that will help someone get me pointed in the right direction???

Sounds like you should post the contents of the share.cfg files involved.  We know what you think you've configured... but obviously, something you are not considering is in effect.

 

What version unRAID are you running?

 

Joe L

I'm running 4.4.2

 

I've attached a copy of 2 of my shares' .cfg files along with a screen shot from the web interface (in case you see anything funny).

 

For most my shares the only difference is the split level. The only exception is the "ApertureVault" share which forces everything to be on disk1 (don't know if that's a clue or not).

 

Thanks,

Kyle

Video.cfg

ApertureVault.cfg

Joe,

Sometimes I just need the right question to change my focus and get me pointed down the right path. I think I stumbled onto the solution for both problems (using the wrong disk based on free space AND throwing an error when copying a large file).

 

My "Video" share was setup with split-level = 3. Later I added an additional directory level and manually moved the files around to fit into that organization scheme (on both disks). But I did not change the split-level. When I try to copy a file to "Video/Library/Movies/Rated PG" it finds a "Rated PG" folder on disk1 and since it's already below the split-level I think it disregards the free space thing and starts copying there. I'm sure I over simplified it, but could that explain why it always went to the same disk (regardless of the free space)?

 

What I can't explain is why it caused the copy to drag down to such a slow speed (which I suspect is what caused the error to get thrown). As I mentioned above, copying files with FTP was painfully slow but it would eventually succeed.

 

In any case. I set the split level to 4 and it all works as before. It chooses which disk based on free disk space and the drag-and-drop copies are as fast as they ever were. I know "fast" is relative (I don't have a cache disk), but it's an acceptable rate of around 1GB per minute (wall-clock time). I just copied around 20GB and it chugged along just fine. No errors, checksums are good, etc.

 

Thanks for the kick in the pants.

 

Kyle

Joe,

Sometimes I just need the right question to change my focus and get me pointed down the right path. I think I stumbled onto the solution for both problems (using the wrong disk based on free space AND throwing an error when copying a large file).

 

My "Video" share was setup with split-level = 3. Later I added an additional directory level and manually moved the files around to fit into that organization scheme (on both disks). But I did not change the split-level. When I try to copy a file to "Video/Library/Movies/Rated PG" it finds a "Rated PG" folder on disk1 and since it's already below the split-level I think it disregards the free space thing and starts copying there. I'm sure I over simplified it, but could that explain why it always went to the same disk (regardless of the free space)?

 

What I can't explain is why it caused the copy to drag down to such a slow speed (which I suspect is what caused the error to get thrown). As I mentioned above, copying files with FTP was painfully slow but it would eventually succeed.

 

In any case. I set the split level to 4 and it all works as before. It chooses which disk based on free disk space and the drag-and-drop copies are as fast as they ever were. I know "fast" is relative (I don't have a cache disk), but it's an acceptable rate of around 1GB per minute (wall-clock time). I just copied around 20GB and it chugged along just fine. No errors, checksums are good, etc.

 

Thanks for the kick in the pants.

 

Kyle

You are welcome.

 

When reiser file-systems get full they start packing the file into the empty "tail-ends" of data blocks previously used for other files.  In other words, the file can no longer be contiguous on the disk.  This greatly reduces the write speed since the disk head is seeking all over the place.

 

Glad you figured out the issue.  I would not have know which folder you were copying to...

When reiser file-systems get full they start packing the file into the empty "tail-ends" of data blocks previously used for other files.  In other words, the file can no longer be contiguous on the disk.  This greatly reduces the write speed since the disk head is seeking all over the place.

That explains why refreshing the unRAID web page was a little pokey during one of those long, slow copies.

 

I would not have know which folder you were copying to...

Sorry about that. I didn't mention it because I didn't think it mattered - I thought it was a hardware or server-wide issue (that's what I get for thinking, huh?). Your question about the shares is what jarred me lose. I tried the other shares...they worked fine...drilled down to the real problem.

 

Thanks again. The service you provide on the forum never ceases to amaze me.

sorry to hijack this thread - but i am having a similar issue and wanted to know if this was similar (i.e hardware related?)

 

I am logged onto my unRAID server and fired up the FTP and connected to my FTP source, which is my Qnap 209 Pro II nas box. I am trying to use FTP from my unRAID server to transfer FROM my Qnap TO my unRAID box.

 

I can connect, browse around and even transer small files to my unRAID box. The problem is that i cannot download any files over 2GB, i get this error:

 

local: Sample File.mkv: File too large

426 Transfer aborted. Operation not permitted

2147483647 bytes received in 95 seconds (2.2e+04 Kbytes/s)

 

 

I have set the transf mode to binary before i commenced the transfer (by typing in bin) but i still get the error.

 

Any ideas? Is this possibly a problem on the Qnap end?

 

thanks

Error 426 is a pretty standard FTP error (can't remember if it comes from the client or the server - maybe either). Many different things could cause it (firewall, ports blocked, multiple IP addresses on one NIC, multiple NIC's with the same IP address, using passive mode with a server that can't handle that, hard disk error, etc., etc.). I wouldn't indict Qnap just yet.

 

I've never tried what you're doing but here are some things I'd try (if you haven't already) to see if you can rule some things in/out:

- try switching between passive / active mode on your FTP client

- try different files (maybe there's one with a hard disk error)

- try FTP-ing from a different machine (desktop?) using a different FTP client (try both passive/active again)

- try getting the same file another way (i.e. Samba) share

- double check your network and make sure everyone has a proper IP address and there aren't duplicates

- are there any ports blocked between the two servers (firewall, router, gateway, proxy, etc.)

 

If you can't figure it out, you might want to open a new thread specific to your problem. I'm sure there are guys on the forum who know a lot more about FTP than I do - more specifically the FTP client that's implemented on the unRAID OS. Be sure to mention what version of unRAID and Qnap you're using (maybe there are FTP patches to one or both).

 

Good luck.

thanks for the pointers.

 

i tried samba and it works, but it is just slow. I will open a new thread and see if the ftp gurus can help 

 

I may also try the other ftp client (proftpd) with the guidance of some people because the note on unMENU is scary in that it says it replaces vsftpd, so i wouldnt know how to get it back if i couldnt get proftpd working!

 

cheers

Monza

thanks for the pointers.

 

i tried samba and it works, but it is just slow. I will open a new thread and see if the ftp gurus can help 

 

I may also try the other ftp client (proftpd) with the guidance of some people because the note on unMENU is scary in that it says it replaces vsftpd, so i wouldnt know how to get it back if i couldnt get proftpd working!

 

cheers

Monza

Getting vsfptd back is as easy as clicking on the button that says "Disable Re-Install on reboot" on the package manager and then rebooting.

 

As far as getting proftpd working, I don't use ftp to move files to my pc so I can't guide you to configure yours.

thanks for that info JoeL - very useful.

 

Also, I have started my own thread on this issue as i would ideally like to know the answer to the 2GB issue.

 

So please any further replies on this newly created thread:

 

http://lime-technology.com/forum/index.php?topic=5709.0

 

cheers (and sorry again for hijacking this - i feel filthy now lol)

 

 

thanks for that info JoeL - very useful.

 

Also, I have started my own thread on this issue as i would ideally like to know the answer to the 2GB issue.

 

So please any further replies on this newly created thread:

 

http://lime-technology.com/forum/index.php?topic=5709.0

 

cheers (and sorry again for hijacking this - i feel filthy now lol)

 

 

What program are you using to access the ftp server to perform the file-transfers?   (on your PC)  I have read that some of them have limits on file size based on old windows limitations.

 

See here: http://blog.monkeyless.com/2005/11/01/buggy-ftp-size-limits-in-windows-iis/

 

and here: http://mybroadband.co.za/vb/showthread.php?146380-FTP-4GB-file-size-limit&s=69786cc2f4686128384a5006ced56feb&p=2295596&viewfull=1#post2295596

Joe L.