rsync won't recurse - irix

Jerry Adlersfluegel jadlersfluegel at cbiz.com
Sat Oct 4 07:48:16 EST 2003


On Sunday, September 28, 2003, at 08:58  PM, jw schultz wrote:

> On Sun, Sep 28, 2003 at 02:20:20PM -0400, Jerry Adlersfluegel (CBIZ 
> Tech) wrote:
>> I'm using the binary for irix provided on the site:
>>
>> rsync  version 2.5.6  protocol version 26
>> Copyright (C) 1996-2002 by Andrew Tridgell and others
>> <http://rsync.samba.org/>
>> Capabilities: 64-bit files, socketpairs, hard links, symlinks, 
>> batchfiles,
>>               no IPv6, 64-bit system inums, 64-bit internal inums
>>
>> The system is an origin 2000 running 6.5.20.
>>
>> I am doing filesystem replication on a few machines, and on two of 
>> them I
>> have run into a problem where rsync will not descend into directories,
>> regardless of where I start. No directory on the filesystem will rsync
>> properly. Other filesystems work, and it works fine on some systems 
>> even
>> with larger volumes.
>>
>> Here's an example of what I try:
>>
>> winssgi1 21# df -h /raid
>> Filesystem             Type  Size   use  avail  %use  Mounted on
>> /dev/xvm/raid01         xfs  5.1T  922G   4.2T   18%  /raid
>> winssgi1 22# rsync -avP /raid/ /snapshot/backup.0/raid/
>> building file list ...
>> 1 file to consider
>> wrote 40 bytes  read 20 bytes  120.00 bytes/sec
>> total size is 0  speedup is 0.00
>>
>>
>> So, I ran par against rsync, and here is something I noticed in the 
>> one that
>> fails, that doesn't show up on one that runs successfully on a 
>> different
>> filesystem:
>>
>>    13mS[  6]                 : write(1, "building file list ... \n", 
>> 24) =
>> 24
>>    13mS[  6]                 : brk(0x10024000) OK
>>    13mS[  6]                 : lstat64("/raid/.", 0x7fff2da8) OK
>>    14mS[  6]                 : chdir("/raid") OK
>>    14mS[  6]                 : lstat64(".", 0x7fff2488) OK
>>    14mS[  6]                 : write(1, " 0 files...\r", 12) = 12
>>    14mS[  6]                 : open(".", O_RDONLY|O_NONBLOCK, 
>> 02000265070) =
>> 3
>>    14mS[  6]                 : fcntl(3, F_SETFD, 1) OK
>>    14mS[  6]                 : fstat64(3, 0x7fff2048) OK
>>    14mS[  6]                 : brk(0x10028000) OK
>>    14mS[  6]                 : ngetdents(3, 0x10023f40, 16384, 
>> 0x7fff20dc)
>> errno = 79 (Value too large for defined data type)
>>    14mS[  6]                 : close(3) OK
>>    14mS[  6]                 : chdir("/raid/foo/scripts") OK
>>    14mS[  6]                 : write(1, "1 file to consider\n", 19) = 
>> 19
>>
>>
>> Any ideas on how I can get this to work?
>
> That indicates that one of the fields of the dirent
> structure is incapable of holding the data from the
> filesystem.  Take a look at the structure as used by the
> syscall (as opposed to readdir) and look at ls -i
> of the directory.  You might also try par on ls -i to see
> what syscalls it is using.
>
> It could be that there is a new 64bit version of the syscall
> and that needs to be called instead.  I'm afraid that could
> get ugly since we have so far not needed to deal with that
> issue.  More likely is that there is a linking error in the
> build.
>

Ok, I'm finally able to look into this further. I was setting up a 
system with gcc on it, so I was downloading all the necesary packages 
from freeware.sgi.com and I saw the rsync 2.5.6 package was added on 
7/1/03. I've been out of town implementing it for the past two months, 
so I'm not sure how I missed it.

I installed fw_rsync-2.5.6 on one of the affected systems, and this 
rsync appears to be working properly. I appreciate your ideas on 
looking into this.


-- 
Jerry Adlersfluegel




More information about the rsync mailing list