> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@xxxxxxxxxx]
> Sent: Saturday, 20 February 2016 12:19 AM
> To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> Cc: 'Mark Goodwin' <mgoodwin@xxxxxxxxxx>; 'pcp' <pcp@xxxxxxxxxxx>
> Subject: Re: log import needs ability to write mark records?
>
> "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> writes:
>
> > [...] Please note this brings up a case where pmlogextract should
> > _not_ follow the new multiple-archives semantics ... it _really_
> needs
> > to know where each archive ends [...]
>
> 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.
At the moment, pmlogextract does not use any libpcp method to read archives
(there are good reasons for this) and this is only going to work if each
command line argument identifies a single archive, which is why I was
suggesting the need for an additional "how many archives are behind this
multi-archive" function.
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.
So I'd be happy for these tools to only work with single archive arguments.
To allow pmlogextract to work with a multi-archive argument would seem to
require a whole lot of rewriting of pmlogextract plus additional libpcp
functionality (e.g. to enumerate all the archive names behind a
multi-archives and then let these tools continue the way they operate
today).
Basically these tools are not helped by the multi-archive abstraction that
is useful for general PMAPI clients, as they need to know about the end of
each archive.
|