----- Original Message ----- > On Mon, Mar 30, 2015 at 5:21 AM, Jesper Derehag <jdere...@hotmail.com> wrote: > > No thoughts on this one? > > > > Den 25 mar 2015 16:53 skrev Jesper Derehag <jdere...@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@lists.lttng.org > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > > > _______________________________________________ > > lttng-dev mailing list > > lttng-dev@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@lists.lttng.org > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev