[lttng-dev] Configurable tracepath?

[Mathieu Desnoyers]

----- Original Message -----
> On Mon, Mar 30, 2015 at 5:21 AM, Jesper Derehag <jderehag at hotmail.com> wrote:
> > No thoughts on this one?
> >
> > Den 25 mar 2015 16:53 skrev Jesper Derehag <jderehag at hotmail.com>:
> >
> > Hi,
> >
> > We have run into an issue with unique per-session tracepaths.
> >
> > In my particular setup I am using relayd to centralize alot of consumers
> > (not really important to this discussion, but thought I'd mention it
> > anyway).
> > So the problem is that I have very limited quota for %outputpath. So to
> > manage the quota fairly between channels I am using --tracefile-size to
> > limit the size of each channel and thus preventing them from starving
> > eachother out.
> > BUT, say I would want to restart the session for some reason, in my case it
> > might be that the card running a specific session reboots, and then relayd
> > would get a new session & channel, and thus create a new folder for that
> > data. But since the old data still remains, I would run into the quota
> > limit..
> >
> > Below is how the tracepaths are created in pseudo-code:
> >
> > per-pid tracing:
> >    tracepath = %outputpath/%pid/%session_name-%pid-%datetime
> >
> > per-uid tracing:
> >    tracepath = %outputpath/uid/%uid/%arch-bit
> >
> > So just reading this little snippet I am guessing one could avoid this
> > particular problem by doing per-uid tracing, but that seems like an
> > unnecessary workaround for what would seem like a trivial problem?
> >
> > Would it instead be feasable to have the channel->path_name configurable,
> > so
> > that you essentially could avoid the uniqueness of the path (pid &
> > datetime)?
> >
> > Or is that instead opening pandoras box w.r.t. to tracefile consistency and
> > contention?
> 
> I *think* this was done to reasonably ensure the uniqueness of the
> trace path since the consumer and relay daemons will not deal with
> existing files gracefully.
> 
> I can see the use case though... It would probably require making the
> consumer and relay daemons a bit smarter if we want them to pick-up
> where they left. Nevertheless, it would be a neat feature.
> 
> In the meantime, I don't really have a good recommendation for you... :-/

Also, in per-PID tracing, we also need to have separate output files for
each process that runs concurrently. Per-UID tracing is meant to share
the ring buffer across processes from the same user, which is not the
case for per-PID tracing.

You might want to try erasing the old trace before starting to record
the new session.

Thanks,

Mathieu

> 
> Jérémie
> 
> >
> > Regards,
> > Jesper
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev at lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
> >
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev at lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
> 
> 
> 
> --
> Jérémie Galarneau
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com