Description of problem: We have two Intel x86_64 servers running RHEL 4. When I tried to rsync the /var file system to either a i386 server or another x86_64 server (the rsync command is run from the remote server), the rsync job hangs on /var/log/lastfile, even if I run rsync with the "--sparse" option. The same rsync command can backup the /var file system on i386 servers just fine. Version-Release number of selected component (if applicable): rsync-2.6.3-1 How reproducible: Always Steps to Reproduce: 1. From a remote server, try to rsync /var/log/lastlog of a x86_64 RHEL 4 server with --sparse option. Actual results: The rsync job hangs on /var/log/lastlog forever Expected results: /var/log/lastlog should be copied to the remote server. Additional info:
Just to be clear: /var/log/lastlog is a sparse file indexed by UID. On 64 bit systems (where UIDs are 32 bits long) it is 1.2TB large. Running rsync with --sparse (I believe) causes it to detect and coalesce large runs of zeros in the input file. It still needs to read the entire block of nothingness to do its job, however. I verified similar behavior with tar --sparse, which appears to terminate only after a very long time. I don't believe it is an infinite hang. Here is a mild flame war on fedora-test-list that might provide more information: https://www.redhat.com/archives/fedora-test-list/2005-June/thread.html#00308 Unless the implementation of the lastlog file format is changed to something other than a gargantuan sparse file (or removed from the distribution -- it is only readable by root and provides very little utility), this is going to be difficult to fix.
Since there is only one more release planned for RHEL4, this issue most likely won't be fixed in it. Considering the circumstances described both in this bugzilla and referenced discussion, I'm closing this bug as WONTFIX.