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