Bug 89835 - dump output file is larger than expected
Summary: dump output file is larger than expected
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dump
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Ben Levenson
URL: http://sourceforge.net/tracker/?group...
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-28 20:32 UTC by Christopher R. Wren
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2003-05-18 04:04:15 UTC

Attachments (Terms of Use)

Description Christopher R. Wren 2003-04-28 20:32:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

Description of problem:
incremental dumps are significantly larger than they should be.  Possibly
related to excluding inodes (-e) and/or ext3.  The sourceforge bug tracker for
dump claims that this is resolved in 0.4b29, but there are no official RH
packages for RH8, RH9, or RawHide that I could find that are newer than

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. do a level 0 dump, excluding inodes
2. do a level 1 dump, excluding those inodes the enxt day
3. copmpare the size of the dump to the size of the files listed by "restore -t"
and wonder at the size of the dump!

Actual Results:  some of my incrementals are as large as 7GB, even though the
files listed by -t only total in the tens of MB.  This can easily overwhelm the
backup medium and result in failed backups.

Expected Results:  the size of the dump should be roughly size of the dumped files.

Additional info:

excluded inodes,
although I haven't verified that any of these are critical to the bug.

I will try to verify that 0.4b29 or later fixed the problem.

Comment 1 Stelian Pop 2003-04-28 21:04:49 UTC
This could be the right time to update dump to the latest version. 0.4b28 is a
year old now, there have been 6 new versions since that one...


Comment 2 Christopher R. Wren 2003-05-16 08:57:17 UTC
installing dump-0.4b34-1 from http://dump.sourceforge.net seems to have resolved
the problem.  My incrementals are now sane!


Comment 3 Mike A. Harris 2003-05-18 01:37:25 UTC
Just a note for the curious...  Red Hat does not track every new version of
an upstream package that might come out over time, and release updated versions
of it for existing OS releases.  So it is possible that many upstream releases
of a given piece of software might occur within a single OS development cycle,
and we're not likely to release any updates until the next distribution release
comes out.

That said, I'll update to the new version in rawhide soon.  

Comment 4 Mike A. Harris 2003-05-18 03:06:50 UTC
I just updated the rpm to 0.4b34-1, however it only builds on x86.  It does
not build on x86_64, so currently, it is less than useful.  ;o/

Defering inclusion in rawhide until I have time to investigate the 64bit build

Comment 5 Mike A. Harris 2003-05-18 03:35:36 UTC
for i in compat/lib compat/include common dump restore rmt; do \
        (cd $i && make all) || exit 1; \
make[1]: Entering directory `/home/mharris/rpmbuild/BUILD/dump-0.4b34/compat/lib'
gcc -pipe -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes                     
    -Wmissing-prototypes -Wno-char-subscripts -I../.. -I../../compat/include
-D_DUMP_VERSION=\"0.4b34\"      -c -o compaterr.o compaterr.c
gcc -pipe -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes                     
    -Wmissing-prototypes -Wno-char-subscripts -I../.. -I../../compat/include
-D_DUMP_VERSION=\"0.4b34\"      -c -o compatglob.o compatglob.c
gcc -pipe -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes                     
    -Wmissing-prototypes -Wno-char-subscripts -I../.. -I../../compat/include
-D_DUMP_VERSION=\"0.4b34\"      -c -o bylabel.o bylabel.c
In file included from /usr/include/sys/param.h:42,
                 from bylabel.c:17:
/usr/include/sys/types.h:194: conflicting types for `int64_t'
/usr/include/sys/types.h:39: previous declaration of `int64_t'
make[1]: *** [bylabel.o] Error 1
make[1]: Leaving directory `/home/mharris/rpmbuild/BUILD/dump-0.4b34/compat/lib'
make: *** [all] Error 1
error: Bad exit status from /home/mharris/rpmbuild/tmp/rpm-tmp.78488 (%build)

RPM build errors:
    Bad exit status from /home/mharris/rpmbuild/tmp/rpm-tmp.78488 (%build)

Comment 6 Mike A. Harris 2003-05-18 03:36:49 UTC
Oops, just noticed I somehow managed to close this as RAWHIDE.  Reopening.

dump 0.4b33 compiles fine on x86_64, so the problem is introduced in 0.4b34

Comment 7 Mike A. Harris 2003-05-18 04:04:15 UTC
dump-0.4b33 compiles on i386, ia64, alpha, x86_64, ppc, s390, s390x so I've
decided to put it in rawhide for the time being as I won't have time to
investigate the above 64bit build problems for a while.  I'll try updating
to 0.4b35 when it's released.

Closing as fixed in RAWHIDE version dump-0.4b33-1

Comment 8 Stelian Pop 2003-05-18 11:00:11 UTC
Mike, I understand Red Hat does not have the ressources to issue bugfixes to
every package for the already released OS versions. However, dump has not been
updated in a while, and this includes *several* OS development cycles.

As for the build problem, I don't have a x86_64 platform to test this on.
Moreover   nobody reported upstream such a compile failure. Couldn't this be
related to a C headers problem ? You compile log shows just that, something
incoherent between two system headers:
    /usr/include/sys/types.h:194: conflicting types for `int64_t'
    /usr/include/sys/types.h:39: previous declaration of `int64_t'


Comment 9 Mike A. Harris 2003-05-18 20:34:23 UTC
Let me try to explain it a bit clearer, so there is no misunderstanding.
dump is a priority 3 package in the distribution, so it gets very low
priority compared to higher priority packages.  When there is a lot of work
that needs to be done on priority 1 and 2 packages, then priority 3 packages
get less attention, and that might mean that they don't get updated for a

Updating a package version is not just a matter of building a new RPM.  The
software must be downloaded, diffs generated between the last version and
the current version, and studied perhaps briefly, or perhaps for hours.
Changelogs need to be read, copyright notices kept track of, licensing
changes investigated, and many other issues that are important.

It isn't a 10 minute job.  It takes time.  That is why dump isn't updated

>As for the build problem, I don't have a x86_64 platform to test this on.

It happens on x86_64, ia64, alpha, ppc64, s390x also. Probably on sparc64.
Looks like a generic 64bit problem.  It might not even be a dump bug though,
it could perhaps be a C library header bug, or something else.  I'm not sure

> Moreover nobody reported upstream such a compile failure.

Sorry, I wasn't implying that you should personally investigate this issue
yet.  I was merely stating that dump 0.4b34 doesn't currently compile
successfully, and I don't have time to find out why yet.  I've put 0.4b33
in, and it built on all platforms, so that fixes this reported bug, and
hopefully a lot of other problems people have reported.  I haven't reported
it upstream because it just happened, and I don't yet know if it is a bug
in dump.  I haven't had time to make an adequate assessment.  But it doesn't
compile in any case, so I can't include it until I do have the time to
investigate it, or if someone else does.

>Couldn't this be related to a C headers problem?

Anything is possible.  That is why I haven't claimed it is a dump bug.  I
only claim that dump doesn't compile on the 64bit architectures I need to
compile it on, and that I don't yet know the cause nor have time to try
and figure it out currently.

>You compile log shows just that, something incoherent between two system >headers:

It's one system header - types.h

I did look at that header, on the 2 lines specified, and neither line
contains anything to do with int64_t, so it is a deeper problem that
will require more time to investigate likely.

I'm not sure why having the absolute latest version of dump is that much
of a mission critical issue though.  However, if someone (anyone, not
just you) wants the latest release in rawhide faster than I'll have
time to devote to it, we accept patches, and appreciate people volunteering
to troubleshoot problems.  ;o)

If I do get a chance to debug this issue, and believe it to be a dump
bug, then I'll file a bug report upstream to track it though.  Until then
though it is just an unknown.  My goal was only to solve bug #89835
and I believe that is fixed now.  ;o)


Comment 10 Mike A. Harris 2003-05-18 21:51:34 UTC
I've just added myself to the file and project tracker for "dump" on
sourceforge, so I'll be alerted automatically when new versions come out.
This may also help to keep dump more updated in the future as well.

Comment 11 Christopher R. Wren 2003-05-23 12:33:54 UTC
> My goal was only to solve bug #89835
> and I believe that is fixed now.  ;o)

Just for kicks I downgraded to the sourceforge 0.4b33 RPM, form the 0.c4b34, 
and it does seem to fix the problem (as it should, according the the CHANGELOG).

Thank you for the fix, and for the peek inside Red Hat proceedures.


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