Red Hat Bugzilla – Bug 206129
Dump output size determined incorrectly
Last modified: 2008-08-02 19:40:34 EDT
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
- 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
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-------------------------- ------------------------------------- -------------
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):
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
Size computed is 1/2 the actual size.
Correct size computation.
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.
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.
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!
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.]
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.
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.