+++ 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 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): 2.5.0p2-3 How reproducible: Always 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 fenlason 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 mb6zcpv02 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 mattdm 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 mb6zcpv02 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 mattdm 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.
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.
As this is minor bug and FC5 is no longer maintained, I'm going to close it. Updating to FC6 or F7 is recommended.