pcp
[Top] [All Lists]

Re: [pcp] pmlogger -u questions

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] pmlogger -u questions
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 13 Apr 2014 20:58:24 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <01e901cf56df$4ce97de0$e6bc79a0$@internode.on.net>
References: <01e901cf56df$4ce97de0$e6bc79a0$@internode.on.net>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: Ac9Wk0u5sliNSYJNTG+IYRoOQpU0FUwylkIw
Thread-topic: pmlogger -u questions
Hi,

----- Original Message -----
> 
> 
> Another one from the developerâs meeting.
> 

I can't remember all of the context of this one, I think it was Frank
who pointed out -u but the context is eluding me...

> 
> The âu option to pmlogger is not really unbuffered. Weâre still using stdio
> and stdio buffers and stdio default buffer flushing, but weâre adding
> fflush() calls in the correct order (meta data file, data file, index file)
> at the end of each logical record written to the archive (after each
> pmFetch).
> 

*nod*

> 
> This closes, but does not remove the time window in which the physical files
> are not consistent and aligned with the end of a logical archive record.
> 

Is our concern about "not consistent" here on-disk or in-memory consistency?

> 
> -u can be passed to all the pmloggers being managed by pmlogger_check and
> friends by adding âu to each line in the control file.
> 

Not clear who (which tools?/code?) benefit from that, if anyone...?

> 
> As I see it, we have 3 options:
> [...]
> Thoughts? Comments?
> 

I think we need some demonstrated, concrete, actual issues here - its all a
bit too hypothetical at this stage - a (QA?) tool that attempts to read from
the end of a growing log file for starters, and the clear existence of some
problems, before we start fixing them.  Do we have such a QA tool already?
(reading the cases covered in pmGetArchiveEnd in libpcp suggests we might?)

thanks.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>