>Even better: run the dumps till they start outputting data. Stall the
>output pipe until the data is needed.
>
>That way the "estimation" step of dump that actually happens in the
>end is not repeated for the eventual dump.
That's an interesting idea, but would have several implementation
problems. For one, Amanda runs one, two or three estimates of each file
system, so even on a fairly small system you're talking about dozens
of dump processes hanging around, possibly more than are allowed for a
single user. On several of my systems we would be talking hundreds of
processes (although they would mostly be asleep).
They would have to stay there until the planner stage completes, at which
time we know which one or two (in case we have to drop back to degraded
mode) will be used during the run, then any remaining could be killed.
The data cannot just be stalled on the client. Dump outputs several
blocks before the estimated size line and those would have to be saved.
Then when the real dump is requested, those blocks would have to be
sent along to the new socket connected to a dumper and the rest of the
data flow would also have to be collected and sent along (much like it
does now).
We would also probably need some kind of keep alive since it could be
hours between the start of dump and the actual data motion.
It would also have to allow for a dump to be aborted and restarted,
which happens during direct to tape when an error is detected.
Finally, this only applies to dump. GNU tar does its estimates in
a completely different way (it literally does the dump to /dev/null,
with an efficiency shortstop that skips any real I/O, and just outputs
the total size when it is completely done) and would not gain anything
with these changes.
As I said, it's an interesting idea and worth some more thought, but
will take significant changes to the way Amanda does things (which is
not necessarily a bad thing).
> Roger.
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
