samba-bugs at samba.org
2018-Jun-29 12:52 UTC
[Bug 13496] New: lseek returned -1, not 2147483648: Invalid argument (22)
https://bugzilla.samba.org/show_bug.cgi?id=13496 Bug ID: 13496 Summary: lseek returned -1, not 2147483648: Invalid argument (22) Product: rsync Version: 3.1.2 Hardware: Sparc OS: Solaris Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter: samba.pkoch at dfgh.net QA Contact: rsync-qa at samba.org Dear rsync experts: We are rsyncing our file servers /home-directory with approx 1TB data every night by using the following command: rsync --password-file=/etc/backup.pass -aHA \ --link-dest=../<backup-dir from last night> \ /home/ v480 at backup::v480/home/<new backup-dir> The sending server is a Sun machine running Solaris 10, the receiving machine runs Slackware Linux 14.2. For a long time we were using rsync 3.0.8 on the Solaris 10 machine and rsync 3.1.2 on the backup.server and everything was fine. Two month ago we decided to rsync ACLs as well and this forced us to upgrade rsync on the Solaris machine to a newer version. I decided that using the exact same version on both machines would be the best situation and so I compiled rsync 3.1.2 on the Solaris machine with sh configure --prefix=/usr; make; make install Again everything was working fine (including ACLs) but since 3 days rsync stops every night with the following error message: rsync: lseek returned -1, not 2147483648: Invalid argument (22) rsync error: error in file IO (code 11) at fileio.c(249) [sender=3.1.2] I suspected a largefile-problem, but none of our files is of size >2GB. Sometimes the rsync-command is successfull when we restart it in the morning. SOmetimes the problem still happens when the command is restarted and we then rsync each subdirectoy separately. When using the verbose-option we see that rsync fails at different locations within the file tree. It seems to me that some kind of 2GB-limit is reached. I looked into the source code to find out why rsync is doing a lseek(2GB). But this gave me no ideas about what's happening. errno=22 indicates that lseek was called with invalid parameters. But rsync --versions shows: rsync version 3.1.2 protocol version 31 Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, no symtimes, no prealloc So we do have largefile support. The only way to reproduce this problem is to rsync the complete 1TB. Is there any other debugging information that I can print in line 249 of fileio.c and that might help you to diagnose the problem. Kind regards Peter Koch -- You are receiving this mail because: You are the QA Contact for the bug.
samba-bugs at samba.org
2018-Jun-29 16:05 UTC
[Bug 13496] lseek returned -1, not 2147483648: Invalid argument (22)
https://bugzilla.samba.org/show_bug.cgi?id=13496 --- Comment #1 from Peter Koch <samba.pkoch at dfgh.net> --- (In reply to Peter Koch from comment #0) Our Sun Solaris 10 machine is a 64bit system but our gcc compiler creates 32bit executables if not told otherwise root at v480# file /usr/bin/rsync /usr/bin/rsync: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped I was hoping that my problem would go away if rsync was compiled as a 64bit binary. So I recreated rsync with sh configure CFLAGS=-m64 --prefix=/usr; make; make install root at v480# file /usr/bin/rsync /usr/bin/rsync: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped But both exectables fail with the same error message Peter -- You are receiving this mail because: You are the QA Contact for the bug.
samba-bugs at samba.org
2018-Jun-30 08:25 UTC
[Bug 13496] lseek returned -1, not 2147483648: Invalid argument (22)
https://bugzilla.samba.org/show_bug.cgi?id=13496 Peter Koch <samba.pkoch at dfgh.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Peter Koch <samba.pkoch at dfgh.net> --- (In reply to Peter Koch from comment #0) Dear readers: Problem has been solved, Here's what was going on: 1: I was (partly) wrong when stating that there were no files with size >2GB in our /home-directory 2: Both 32bit and 64bit executables on Solaris 10 do support largefiles. So does rsync. 3: One of our administrators created a NFS link from our mailserver into our fileservers /home-directory and for some reason forced the Solaris machine to use NFS version 2 4: 3 day ago a file of size>2GB was created on our mailserver. rsync detected this file within the /home-directory. It had size >2GB but due to the NFS version 2 limitation only the first 2GB of this file were readable. So lseek(2GB) returned -1 Now I'm using rsync -aHAx instead of rsync -aHA and everything works fine again Thank you all for this wonderfull software Peter -- You are receiving this mail because: You are the QA Contact for the bug.