Re: Compression Ratio misprinting on labels
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
Re: Compression Ratio misprinting on labels
Phil Homewood wrote: Upgraded one box to 2.4.4p3. amreport still shows the bogus labels when run against a log generated under 2.4.4p2. Tonight I'll see what it does when it creates the log itself. :-) Do you mean you upgraded a client? Just the amanda server is fine. The 2.4.4p3 server is compatible with older clients. (Does amreport pull its stats from anywhere but the logfile?) It also needs the amanda.conf and the disklist file. I should delve into the source code to find out what exact information it gets from there (e.g. columnspec, mailadress come to mind). If you like, you may send me such a log file, so I could have a look at the strange things it calculates. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Compression Ratio misprinting on labels
Paul Bijnens wrote: Upgraded one box to 2.4.4p3. amreport still shows the bogus labels when run against a log generated under 2.4.4p2. Tonight I'll see what it does when it creates the log itself. :-) Do you mean you upgraded a client? Just the amanda server is fine. The 2.4.4p3 server is compatible with older clients. Sorry, yes, I meant I upgraded the server. (one box here being one of two amanda servers.) (Does amreport pull its stats from anywhere but the logfile?) It also needs the amanda.conf and the disklist file. Yup, but there are no stats there. I should delve into the source code to find out what exact information it gets from there (e.g. columnspec, mailadress come to mind). My columnspec is unspecified (ie, default). (That was one of the things I initially suspected -- a missing column width causing a snprintf() to get confused, for example. Doesn't appear to be the case.) If you like, you may send me such a log file, so I could have a look at the strange things it calculates. We'll see what happens in tonight's run with 2.4.4p3 :-) I did manage to whittle down the logs (trimming all but one DLE from them) to a state where I could trigger the bogus behaviour by changing only limited info. But I didn't completely exhaust all the options there before deciding that the upgrade to 2.4.4p3 was perhaps a better idea. :-) It *looked* like it was getting the orig-kb value from thin air, as changing that had no effect on the label (but changing the kb did.) That's why I asked about amreport pulling stats from other places. But I'll explore that idea further tomorrow, if 2.4.4p3 still misbehaves. The configs I'm using have grown up from (I think) 2.4.1 or thereabouts. They've been around (and been hacked up occasionally) for several years. So there's possibly something missing that 2.4.4p[23] expects to see...
Re: Compression Ratio misprinting on labels
Paul Bijnens wrote: Mine are correct -- running 2.4.4p3. The oldest postscript labels I have near to me, are from the 2.4.4p2-200405010 snapshot and they are fine too. I'm guessing something a little odd with my config, then. Try upgrading. Upgraded one box to 2.4.4p3. amreport still shows the bogus labels when run against a log generated under 2.4.4p2. Tonight I'll see what it does when it creates the log itself. :-) (Does amreport pull its stats from anywhere but the logfile?) -- Phil Homewood, Systems Janitor, http://www.SnapGear.com [EMAIL PROTECTED] Ph: +61 7 3435 2810 Fx: +61 7 3891 3630 SnapGear - A CyberGuard Company
