Bug 156809

Summary:	rsync --sparse cannot copy /var/log/lastlog on x86_64 server
Product:	Red Hat Enterprise Linux 4	Reporter:	Steven Lee <shl1>
Component:	rsync	Assignee:	Jan Zeleny <jzeleny>
Status:	CLOSED WONTFIX	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	andy
Target Milestone:	---	Flags:	shl1: needinfo-
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	827429 (view as bug list)		Environment:
Last Closed:	2010-03-05 09:34:15 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):

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:

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
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.

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.