On Saturday 20 December 2003 02:30, Georg Rehfeld wrote:
>Hallo Karsten, dear Amanda users,
>
>> i am wondering if it is possible to check how much data is already
>> written in the curent run of amdump/amflush.
>>
>> In the output of amstatus is just an overwiev per filesystem, but
>> i am interested how much of that particular filesystem is already
>> on tape and for example the estimated time.
>
>As I was/am interested in the progress of Amanda too I was motivated
>enough to enhance amstatus into producing (X)HTML output and to be
> used as a CGI script.
>
>Though amstatus, as it is, only gives summary information, it
> already parses all important information from the amdump(.X)
> file(s). Internally it knows many things like start/end times of
> individual dumps or tape writes, sizes of files, compression ratio
> etc. That is, what I exploit partly with my extension and reveal it
> (I hope nicely) formatted.
>
>What amstatus does not have (as it isn't contained in the amdump(.X)
>files) is real progress information.
>
>| Gene Heskett wrote:
>| > The pointers into the filesystem representing the files
>| > currently seeked position are private to tar.
>
>Amanda can't record progress in the amdump files, because the actual
>dumping is done via third party programs, like dump/restore or tar.
>There is no interface for reporting progress with all the different
>external dump programs. Thus only start and end of a dump are
> recorded and directly available to amstatus.
>
>But: amstatus, while a backup is running
>- CAN look at the file size of the holding disk files, even when
> they are just written, with some error, sure, but good enough for a
> valuable estimate most of the time.
>- CAN estimate (very rough) times of dumps done directly to tape
> from calculations of average dump/tape speed and the estimated
> size of the dump. This may be _very_ rough, as stop/rewind/start
> times of a tape not streaming are simply unknown to amanda at all.
>
Yes, this would be the great unknown if the machine is so slow as to
not be able to keep the drive streaming. Certainly not a problem
here with a 400k/sec drive and a 1450mhz machine. But, given the
write speed obtained on those disklist entries that have been
finished, it seems to me that a reasonable estimate of the current
files progress, based on current time-start time and that transfer
rate, could be guessed at and displayed.
That would not take any mods to amanda. :-)
IMO, if mods to amanda were required, maybe its time to take a long
hard look at George Schilling's 'star'. Among other things star can,
if the controlling tty sends it a ^\, it will spit back out to the
controlling tty, a sumary of progress within the current operation.
'star' is, or can be made totally compliant with the POSIX standards
as they existed in 1998, something the gnutar seems to find a moving
target, what with the problems we're once again having with it. It
can also be linked or copied to other names, and will change its
behaviour to conform to the name its been invoked as. Even the
so-called normal tars performance can be achieved, whatever that
might be since we don't really know whats normal for tar these days.
However, I'll leave that exercize to someone a lot more familiar with
the amanda/tar interface than I am.
Time for a 2.6.0-alpha amanda that uses star maybe?
>What I would like to have recorded in the amdump files is
>_taper_progress_, as this seems to me easily determinable by
>amanda and would help a lot in the detailed display.
>
>For a sample (still that well known one pre alpha HTML, don't visit
>now, if you have seen it already; a major update will be in place
>Sunday evening) look at:
>
> http://www.osgev.de/other/amanda/index.html
>
>That is (now) the output of a finished backup (ignore the 'just
> running' message, it's a pre alpha error).
>
>Please note, that, while a backup is running, the output _indicates_
>progress already (partially as is):
>
>- the overview lines are colored differently, indicating partition
> state - the overview percentage bars (done with considerable
> effort, thanks to my son Hauke) ain't fake: they give estimated
> progress of the partition dumping/taping.
>
>Missing in the pre alpha is the progress estimate in the detailed
> view and summary information is missing at all, including the
> estimated time to finish the whole backup.
>
>Just now I have converted my old 2.4.2 work to 2.4.4, while trying
> to still support 2.4.2, changed the output to work well even with >
> 80 partitions backed up and a total backup time of > 12 hours.
> Please DON'T look at the samples (URL above) before Sunday,
> 2003-12-21 20:00:00 if you have seen them before.
>
>Happy christmas
>
>Georg
Merry Christmas to all
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
