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.