cp command failing for large files - Input/Output error
I am having trouble copying large files between Linux boxes. At home I have two Linux boxes, boxA and boxB. Both are running RedHat 8, and have been no problem for years.
boxA has a directory on boxB automounted. For working with most files it's fine. But for large files, when I do a cp from a native directory on boxA to the mounted filesystem, I get input/output errors. To wit:
(where zzz is the very large file and xxx/yyy is the mounted directory)
cp zzz xxx/yyy
cp: writing 'xxx/yyy/zzz': Input/output error
There is not a hard threshold where copy commands fail. I have successfully copied a 43MB file, but have choked on a 35MB and a 138MB file. There is no other activity on either system. Given that, I have not been able to quantify the threshold or conditions that cause the cp command to barf.
I have played around with the automount timeout variable. Changing it has made little difference. It's currently set for two hours. There's nothing conclusive here that makes me believe it's an automount error.
Both the source and destination directories reside on disks with lots (40G+) of free space. The filesystems are nowhere near full.
One interesting thing is that both of these directories are also mounted on a Win2k box via Samba. I am able to do a drag and drop copy. It takes several minutes, but it succeeds.
I have done a search of the forums here and came up with several threads that might be related. None have a definite resolution attached. I'm wondering if they're all due to the same cause:
Does LQ have any suggestions on ways I might be able to do this cp? This problem originally showed up in a simple backup script I wrote, but reproduces rather easily from the command line. I'd rather not have to resort to using windows, as I'm attempting to backup some directories. Once I can successfully copy all files via `cp` I plan on incorporating the fix back into my script.
And welcome to LQ!
Have a look at dmesg output on both boxes, and maybe /var/log/[messages|debug|syslog]
It may be a problem with the network card on one of them.
Thanks. No obvious problems in dmesg. I saw in the messages logfile that it was having trouble mounting a non-existant directory. It looked like some cruft from back when I was trying to get automount to work. I'll see if I can trace it down and clean it up, but it seems incidental and not related.
I'm leaning against it being a network problem simply because I can do things with the file, like view it using `less` or doing the copy via the W2K box from one to the other.
But in any case I'm still poking around to hopefully find the problem.
Maybe try rsync instead? Whenever I have to move files between systems I use either rsync or scp.
I don't know if rsync resides on RH8 but if it does you can try using it. If you have sshd (as most system do) running you can tunnel that way without worrying about an rsync daemon. Try something like:
Check your available disk quota
I had this problem and it was resolved by freeing up some space on the destination disk!
Are you sharing the directory via nfs to your linux box ?
I would do some experiment to isolate the problem. But first I will try to schematize the scenario
Try in boxB to dd if=/dev/zero of=/directory_on_A/file
and see if it stops well stop it after a couple of gig :D, if it stops before you may try to mount it manually and repeat the test.
If it doesn't fail again it's almost surely automount causing the issue.
|All times are GMT -5. The time now is 12:59 AM.|