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
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
