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 235528 - Dump output size determined incorrectly
Summary: Dump output size determined incorrectly
Alias: None
Product: Fedora
Classification: Fedora
Component: amanda
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Radek Brich
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-06 19:05 UTC by Andrew Kroeger
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-13 08:16:49 UTC

Attachments (Terms of Use)

Description Andrew Kroeger 2007-04-06 19:05:04 UTC
+++ This bug was initially created as a clone of Bug #206129 +++

Description of problem:
After amanda completes the backup of a volume using dump, it incorrectly
determines the number of bytes output (before compression, if any).

An example from one of my backup partitions (all of my partitions exhibit this
behavior) is:
- From /var/log/amanda/sendbackup log:
sendbackup: time 2.190:  55:    size(|):   DUMP: 6670 blocks (6.51MB)
- From the amanda e-mail report (same size also in the partition's info file):
                                       DUMPER STATS               TAPER STATS 
-------------------------- ------------------------------------- -------------
amd64.intern /boot       0    3335    5504  165.0    0:02 2650.0   0:00 64182.8

The output size is always 1/2 of the number of blocks output by dump.  It seems
like amanda may be counting on 512K block size as opposed to 1024K.

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

How reproducible:

Steps to Reproduce:
1. Configure and run an amanda dump backup
2. Compare the output size reported by dump to the size recorded in the status
e-mail and the data in the info file
Actual results:
Size computed is 1/2 the actual size.

Expected results:
Correct size computation.

Additional info:
The size estimates used by amanda for planning (before the dumps are performed)
are correctly calculated.  This seems to really mess with the planner (at least
when using the bumppercent config option).  The estimates come out approximately
double what amanda has in its history for the partition, causing it to not bump
to higher level (smaller) dumps.

I checked on both i386 and x86_64 machines in my environment, and this
miscalculation occurs on both platforms.

-- Additional comment from on 2006-09-26 16:12 EST --
I've got a small patch that appears to work in my test setup.  I have a few 
other bugs to deal with before I push new packages, however. 

-- Additional comment from on 2007-01-31 21:11 EST --
Thanks for the patch, Jay.  Everything works great.

Any chance this patch can be back-ported to FC5?  I just had to tie a production
FC5 machine (sorry, not by my choice) into my backups, and I'm seeing the same
incorrect dump size behavior now from FC5.  It would be great to get this
updated before the FC7t2 cutoff for FC5 updates, as I have a feeling that the
PTB won't be too keen on updating this particular machine for quite a while.

If all else fails, I know I can back-port the patch myself, but it would be nice
to get this (and all other applicable updates) into the official FC5 packages
before the updates are stopped.

Thanks for anything you can do!

-- Additional comment from on 2007-04-06 12:14 EST --
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]

-- Additional comment from on 2007-04-06 14:43 EST --
Thanks for pinging me on this one.

As I indicated in Comment 2 above, the fix Jay provided worked fine.  It was
released with FC6.

I am now in a situation where rolling the same update into an updated FC5
package would be helpful.

As a related question, how is backporting normally handled within different
product releases?  If an issue is discovered in FC6, when a patch is added are
checks done to see if the same patch is needed for the FC5 packages?

If not, how should I handle a case like this in the future?  Should I file a bug
against each release?  For tracking purposes, I don't think I should be changing
the release (i.e. from FC6t2 -> FC5) if the bug also applies to FC5.  Any
insight that can be provided will allow me to report bugs without placing any
extra burden on those who are charged with fixing the bugs.

-- Additional comment from on 2007-04-06 14:47 EST --
Thanks. I'm going to mark this one as closed:current release. Then, you should
use the "clone as bug" link up near the top of the page to clone into FC5.

Comment 1 Andrew Kroeger 2007-07-06 09:45:48 UTC
Any chance this can be taken care of?

It's real discouraging to have this bug filed for 3 months and still have it as
"New", especially when it's a simple one-liner that needs to be backported from FC6.

Comment 2 Radek Brich 2007-07-09 13:46:30 UTC
As this is minor bug and FC5 is no longer maintained, I'm going to close it.
Updating to FC6 or F7 is recommended.

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