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):
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.
The rsync job hangs on /var/log/lastlog forever
/var/log/lastlog should be copied to the remote server.
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
Here is a mild flame war on fedora-test-list that might provide more
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.