On Tuesday 23 April 2002 06:33 am, Niall O Broin wrote: >I'm just starting using Amanda (hence the level of questions :-) > ) and I currently am backing up 4 filesystems on 2 hosts though > I want to increase this as soon as I'm happy with what's going > on. I'm currently puzzled about the size of level 1 backups. > Look at these two extracts from mail reports: > > >Makalu TIZ AMANDA MAIL REPORT FOR April 16, 2002 > >DUMP SUMMARY: > DUMPER STATS > TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% > MMM:SS KB/s MMM:SS KB/s -------------------------- > --------------------------------- ------------ moca 26593602659360 -- 13:063385.2 30:251457.5 Unforch, my email agent, kmail, insists on screwing with the format when I'd druther it didn't.
The above error is because in server-src/reporter.c, the format is apparently way old, and not up to the sizes shown by modern multigigabyte systems. The 26593602659360 above s/b broken into 2659360 2659360 so that the original KB and out-KB stats are seperated by a space. Up until the most recent 2.4.3b3 build, I've been editing repo > > >Kindest regards, > > > >Niall O Broin rter.c to fix that before I build each new version. Unforch, reporter.c seems to have been rather heavily modified, and an admittedly very cursory glance at the new code hasn't shown me where to fix it if indeed it still needs fixed. That will have to wait till I see the report from tonights backup as I built that version after last nights backup had already run. There are a couple of other places in the reports columnnar format that also needed the 'space' value in the older code changed to a one from a zero in order to insert that missing space thats used in case the numbers get big. Apparently that part of the code has been re-written, and will hopefully no longer need to be massaged by each builder, but that thumping sound you hear is me knocking on wood of course :-) moca > /boot 0 4384 4384 -- 0:0014986.3 0:13 > 339.3 pumori / 0 40461764046176 -- Same here, it should be 4046176 4046176 and... > 17:52 3773.5 54:45 1231.5 pumori /boot 0 3552 > 3552 -- 0:014089.4 0:05 713.0 > > >Makalu TIZ AMANDA MAIL REPORT FOR April 23, 2002 > >DUMP SUMMARY: > DUMPER STATS > TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% > MMM:SS KB/s MMM:SS KB/s -------------------------- > --------------------------------- ------------ moca / > 1 2671232 2671232 -- 8:43 5109.6 N/A N/A moca > /boot 0 4384 4384 -- 0:0010109.8 N/A > N/A pumori / 1 4047968 4047968 -- > 15:51 4256.4 N/A N/A pumori /boot 0 3552 > 3552 -- 0:016 062.2 N/A N/A > >(Note that there were intervening dumps, but 23 had both / > filesystems at level 1 and I went back to 16 to get both at > level 0. Why on earth are the backups at level 1 bigger than > those at level 0 ? Note that these are both Linux boxes so a > substantial chunk of / is the OS installation and associated > files and there simply hasn't been that much changed on those > boxes. > >I'm using GNU tar version 1.3.18 and with the recent discussion, > I intend to update that today to 1.3.25 from the FSF > development box. > >A second question, while I have your attention. Observe how the > some of the figures in the report run together - is the layout > of this controllable via a template ? The output is 73 > characters so there could be a couple more spaces inserted and > still stay < 80 characters which I imagine is desired. Since you are reading it with the 'mail' command, the 80 column requirement is entirely between you and the current screen size setting and font in use when running X. I've got screen width for nearly 200 chars here. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.8+% setiathome rank, not too shabby for a hillbilly
