> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@xxxxxxxxxx]
> Sent: Saturday, 20 February 2016 6:51 AM
> To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> Cc: 'Mark Goodwin' <mgoodwin@xxxxxxxxxx>; 'pcp' <pcp@xxxxxxxxxxx>
> Subject: Re: log import needs ability to write mark records?
>
> ...
> 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.
Not with the code base today ... the magic archive switching that Dave's
added below the context layer is in libpcp ... pmlogextract does not use
this to read the archive it has its own customized "get the next log record"
routine that replaces __pmLogRead() (to see why you'll only need to stare a
diff of the two routines). So I'd expect it to open the multi-archive
context, but then only process whatever archive is the current one after the
context is set up ... presumably the first in temporal order.
> ...
> 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.
Yep, that would do the trick just fine ... pmlogextract would require
pmGetContextArchives() to return 1 for each command line input archive name.
>
> > 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!)
I don't see these as PMAPI clients ... PMAPI clients operate streams of
performance data with some metadata and ancillary services. The tools that
operate on PCP archives are doing something special and quite different in
my world view.
|