[lttng-dev] Configurable tracepath?

[Jérémie Galarneau]

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... :-/

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