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.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt