Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156809 - rsync --sparse cannot copy /var/log/lastlog on x86_64 server
Summary: rsync --sparse cannot copy /var/log/lastlog on x86_64 server
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rsync
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jan Zeleny
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-04 13:22 UTC by Steven Lee
Modified: 2016-11-28 13:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 827429 (view as bug list)
Last Closed: 2010-03-05 09:34:15 UTC
Target Upstream Version:
shl1: needinfo-

Attachments (Terms of Use)

Description Steven Lee 2005-05-04 13:22:08 UTC
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 22:13:24 UTC
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 09:34:15 UTC
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.