Hi, Ken -
Thanks for the explanation.
On Sat, Feb 20, 2016 at 06:30:18AM +1100, Ken McDonell wrote:
> [...]
> > Isn't that exactly what the <mark>'s in an input archive are for?
> > When pmlogextract is given a multi-archive, it should work the same
> > way as upon an archive that was itself composed from multiple
> > generations of pmlogextract (being merged multiple times) outputs.
>
> Frank, the issue I was raising is that pmlogextract needs to know about the
> end of an _input_ archive so it can insert an appropriate <mark> record in
> the _output_ archive.
If pmlogextract were to consume a multi-archive, or an input archive
that was formerly glued together from multiple parts, it would receive
input <mark> records to correspond to the ends of the input archives.
So it would just need to transcribe those into the output - something
it presumably already does.
> At the moment, pmlogextract does not use any libpcp method to read
> archives (there are good reasons for this) [...]
(Well, it does first open it with pmNewContext, so there's that.)
> I was suggesting the need for an additional "how many archives are
> behind this multi-archive" function.
Dave and I were talking about an API to help with the pmlogreduce
type-changing BZ; it could also serve this purpose:
int pmGetContextArchives(char ***names, int **sts);
... so based on the sts[i] one can tell whether the given name[i] is
ok, or what reason pcp multi-archive rejected it (OVERLAP, et.c)
The rc could be the archive count, which would serve your purposes.
> Tools like pmlogextract, pmlogcheck and pmlogreduce should all be considered
> as "extensions" of libpcp, and closer to pmlogger than general PMAPI
> clients. They consume and create archives directly and as such know about
> the on-disk structure and the internal libpcp data structures. I think this
> is OK and does not need to change.
pmlogcheck, being fed a possibly-corrupted archive, I can certainly
see. The other tools seem like they should be implementable in normal
PMAPI. (They'd eschew the benefits brought by those those good
reasons for the status quo, whatever they mey be!)
- FChE
|