Bug 145678 - Problem with sparse files : tar and cp also !!!
Summary: Problem with sparse files : tar and cp also !!!
Status: CLOSED DUPLICATE of bug 146214
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: tar   
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-20 16:38 UTC by Nathalie Viollet
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-28 11:43:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nathalie Viollet 2005-01-20 16:38:57 UTC
Description of problem:

The command:
  # tar cSvfz /tmp/test.tgz /var/lib uses 100% of CPU and never stops
After some tests we could see that the "blocking" files 
are /var/lib/slocate/slocate.db and /var/lib/rpm/*db.*
If we do not use the S option, the backup finishes but the untar 
create huge files for slocate.db and *db*.
We supect the rpmlib library to be the cause of the problem as it is 
both used by slocate and rpm

Version-Release number of selected component (if applicable):
 This problem appears on Redhat WS 3.0 Update 4 for x86_64(EMT_64 and 
Opteron) and IA64

How reproducible:
   This is 100% reproductible on all system we have currently 
installed with RedHat 3.0 WS Update 4

Steps to Reproduce:
1.# tar cSvfz /tmp/test.tgz /var/lib 
Actual results:
Tar command never finish and gets stuck with few megabyte written on 

Expected results:
Tar command creates a file of a correct size containing all files 
in /var/lib. (This is the behaviour under RedHat WS 3.0 Update 3)

Additional info:

Comment 1 Peter Vrabec 2005-01-26 14:09:45 UTC
I have problem to reproduce it.

What version-release of tar do u use?
Why do u suspect rpmlib is cause of tar failure?

Comment 2 Nathalie Viollet 2005-01-26 14:35:53 UTC
I am using the tar provided in the redhat distribution

I use the -S option to handle effiently sparse file
    tar cSvfz /tmp/test.tgz /var/lib 
never ends using 100% of CPU for hours

The first file that was bloking was slocate.db, so I removed it.... 
then the RPM db files blocked also ....... (I can not remove them !!)

rpm -qR, I can see that slocate and rpm needs the same library :
I deduced it was the library handling such type of files

Same command run on a ReDHat 3 update 3 runs fine.

We have tested the problem on a x86-64 and on a Itanium system, I 
will setup a x86 system to check if it happens also.



Comment 3 Peter Vrabec 2005-01-27 12:43:15 UTC
# tar cSfz /tmp/test.tgz /var/lib
tar: Removing leading `/' from member names
# tar tzvf /tmp/test.tgz | grep db
-rw-r--r-- root/root     16384 2005-01-20 17:33:53 var/lib/rpm/__db.001
-rw-r--r-- root/root   1318912 2005-01-20 17:33:53 var/lib/rpm/__db.002
-rw-r--r-- root/root    663552 2005-01-20 17:33:53 var/lib/rpm/__db.003
-rw-r----- root/slocate 2820342 2005-01-27 04:04:11
-rw-r--r-- root/root          0 2005-01-26 18:42:11 

# uname -a
Linux test151.test.redhat.com 2.4.21-27.EL #1 SMP Wed Dec 1 21:54:21
EST 2004 ia64 ia64 ia64 GNU/Linux
# cat /etc/issue
Red Hat Enterprise Linux AS release 3 (Taroon Update 4)
Kernel \r on an \m
# rpm -qi tar
Name        : tar        Relocations: (not relocatable)
Version     : 1.13.25    Vendor: Red Hat, Inc.
Release     : 13         Build Date: Tue 17 Jun 2003 02:27:08 PM EDT


Comment 4 Nathalie Viollet 2005-03-04 15:23:31 UTC

I rerun the test.
I installed an Itanium with RedHat 3 update 4 with all package

The command :
tar -cS -f /tmp/test.tar /var 
I let the function run for 30 minutes the size of the archive is stuck
at 95815680 bits. The tar process is using 100% of cpu

Running the command 
tar -cSv -f /tmp/test.tar /var hangs.
we can see that on IA64 the last file in tar is /var/log/messages
If I run
tar -cv -f /tmp/test.tar /var  
the tar runs for hour but is progressing. We can see that the file 
after /var/log/messages is /var/log/lastlog

I run further check.
On my system :
mkdir -p /tmp/var
cp -arf /var/* /tmp/var 
hangs also !!!
cp -arfv /var/* /tmp/var 
shows that /var/log/lastlog is the last file trying to be copied

I run the 2 above copy on a similar itanium running RedHat 3 Update 3 
and every thing went fine.

I will rerun all the above tests on a freshly installed opteron server

Comment 5 Peter Vrabec 2005-03-09 09:29:14 UTC
It looks that tar has a problem to handle pretty big sparse files.
See this #146214.

Comment 6 Peter Vrabec 2005-07-28 11:43:18 UTC

*** This bug has been marked as a duplicate of 146214 ***

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