Phil Homewood wrote: > Inconclusive. The email reported an 81.5% ratio where > the printout claimed 81.7. Close, but no cigar... I > think I'll wait and see what tonight's run does...
The compression ratio on my 2.4.4p2 box printed correctly. I think this was purely coincidental. The 2.4.4p3 box still printed an erroneous 94.7% instead of 63.5%. After dicking with printfs in reporter.c, it's obvious that current_tape->corigsize (around line 2127) is erroneous. Running the reporter against a random recent dump, I see current_tape->corigsize as 17040580, whereas it's really supposed to be something like 19919900. It's worth noting that there was exactly one level-0 dump on that tape, and its original size was 17040580. OK, big clue. corigsize appears to be the sum of all level-0 filesystems with compression enabled. No compression? No size. Not level 0? No size. (This comes from checking "kbytes" and "origkb" values around line 1790 of reporter.c, in handle_success().) I get the distinct feeling that something is going badly wrong in the datestamp calculations there. But I'm not exactly sure what they're trying to achieve. Ooh. More clue. Going back to a run with more than one level 0, the result differs depending on what my TZ is when I run amreport. With my normal timezone (UTC+1000), I see an orig of 2784460; setting it to UTC gives 8448980, the difference being one filesystem worth (that FS being the one with no compression enabled.) It was the last FS on the tape. (The correct figure, however, should be 11167052.) Which makes me realise that the ratio in the email report is also bogus, just differently so (or maybe I'm misinterpreting. "Output Size" and "Original Size" are outsize and origsize respectively, however "Avg Compressed Size" is calculated based on coutsize and corigsize. Is that by design?) Anyway. This isn't all that critical, I guess, and I can't really spend much more time investigating. It's an oddity, but it's not causing me any pain except the nagging feeling that /something/ isn't doing the right thing. If anyone has any clues or questions, I'd love to hear them. :-) -- Phil Homewood, Systems Janitor, http://www.SnapGear.com [EMAIL PROTECTED] Ph: +61 7 3435 2810 Fx: +61 7 3891 3630 SnapGear - A CyberGuard Company
