[lttng-dev] Babeltrace2 sink.ctf.fs creating many subdirectories

[Simon Marchi]

On 2020-04-03 8:50 a.m., Muresan, Heman via lttng-dev wrote:
> Hi,
> 
>  
> 
> I’m using bt2 to combine multiple archives and I’m noticing some weird behavior. Not sure if its something on my end.
> 
>  
> 
> I have a bunch of ctf trace archives and I am trying to combine them into one ctf trace archive, this works fine, but when I try to use this ctf trace plugin again to combine traces I notice that it keeps creating subdirectories. Example:
> $ babeltrace2 --output-format=ctf --output tmp/ 20200402T191121+0000-20200402T191133+0000-779 20200402T191133+0000-20200402T191145+0000-780
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit`.
> 
>  
> 
> Now If I try to use this trace to combine again:
> 
> $ mv tmp/a46cbfc6c29d/ .
> 
> $ babeltrace2 --output-format=ctf --output tmp/ 20200402T191145+0000-20200402T191157+0000-781 a46cbfc6c29d
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit-0`.
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit`.
> 
>  
> 
> Repeating the procress:
> 
> $ rm -rf a46cbfc6c29d/
> 
> $ mv tmp/a46cbfc6c29d/ .
> 
> $ babeltrace2 --output-format=ctf --output tmp/ a46cbfc6c29d/ 20200402T191157+0000-20200402T191210+0000-782
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit-1`.
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit`.
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit-0`.
> 
>  
> 
> It created a 64-bit-0 and a 64-bit-1 directory, and if I use this newly created ctf archive again it will create a 64-bit-2 directory. Eventually the directory structure will grow so much that it causes file descriptor problem. Of course, this can be solved by changing the ulimit but that doesn’t seem like the correct approach, especially since then bt2 will just be using more and more resources when its running.
> 
>  
> 
> Anyways, I’m just wondering why it keeps creating more and more directories, if I combine all four archives in one command it only creates one directory:
> $ babeltrace2 --output-format=ctf --output tmp/ 20200402T191121+0000-20200402T191133+0000-779 20200402T191133+0000-20200402T191145+0000-780 20200402T191145+0000-20200402T191157+0000-781 20200402T191157+0000-20200402T191210+0000-782
> 
> Created CTF trace `tmp//a46cbfc6c29d/flight_recorder-20200402T160923+0000/ust/uid/0/64-bit-2`.
> 
>  
> 
> Any help would be appreciated!

Hi Heman,

This is the expected behavior.

Let's say you have three chunks of the same trace: A, B and C.  These three chunks
have the same trace UUID, meaning they can all be decoded using the same metadata.
Here's the definition a the trace UUID, from [1]:

    Trace UUID, used to ensure the event packet match the metadata used.

When you pass A and B through Babeltrace, A and B are recognized to be of the same
trace (they share the same UUID) and are therefore merged in a single output trace.
The output trace, let's call it AB, contains the same logical information as A and
B.  However, the metadata in AB differs slightly from A's or B's metadata.  Since
the packets in AB don't match the metadata from A or B (they can't be decoded using
the metadata from A or B), we can't give it the same UUID.  AB therefore gets
assigned a new UUID.

When you then try to process AB and C, Babeltrace considers them as different traces,
since they have different UUIDs.  The sink.ctf.fs component outputs one trace per
input trace.  So in output, you'll find one trace corresponding to AB and one trace
corresponding to C (they'll have different UUIDs than AB and C).

This is a common misconception that sink.ctf.fs would merge the various traces it
receives into a single trace (probably because that's what the sink.text.pretty
component appears to do).

If you want to merge multiple chunks of a trace, you have to do it in one shot, as
you've mentioned at the end of your message.

If you can share this information, I'd be curious to know the reason why you need
to merge the trace chunks in a single CTF trace, like if you hit some limitation
with some analysis tool by keeping the chunks separate.

Simon

[1] https://diamon.org/ctf/#spec5