Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 156809 - rsync --sparse cannot copy /var/log/lastlog on x86_64 server
rsync --sparse cannot copy /var/log/lastlog on x86_64 server
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rsync (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Zeleny
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-05-04 09:22 EDT by Steven Lee
Modified: 2016-11-28 08:30 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 827429 (view as bug list)
Last Closed: 2010-03-05 04:34:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
shl1: needinfo-

Attachments (Terms of Use)

  None (edit)
Description Steven Lee 2005-05-04 09:22:08 EDT
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.
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:
Comment 1 Andy Ross 2005-06-08 18:13:24 EDT
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


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.
Comment 2 Jan Zeleny 2010-03-05 04:34:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.