[lttng-dev] "No space left on device" results in corrupt trace data set
Yannick Brosseau
yannick.brosseau at gmail.com
Fri Nov 16 10:43:04 EST 2012
It could be interesting to at least reserve the size for the first
packet, so we have at least a little bit of information on the trace.
On 2012-11-16 10:29, David Goulet wrote:
> Hi Paul,
>
> The problem here would be that metadata can grow arbitrarily over time
> when let say new events are enabled during tracing or a new lib is
> dynamically loaded in the application you are tracing. Same goes for the
> kernel for loaded module or CPU hotplug...
>
> To achieve a static size of metadata during the whole life of a tracing
> session, I guess we need somekind of flag or option set to tell the
> tracers to just deny new events once started... which from there, we
> need Mathieu's opinion :)
>
> Cheers!
> David
>
> Woegerer, Paul:
>> Hi,
>>
>> embedded users sometimes have to trace to tmpfs (e.g. streaming in not
>> an option due to missing network connectivity).
>>
>> Ramdisks of 16M to 128M size are created and as long as the ram disk
>> does not get full, tracing works fine. Unfortunately if the disk gets
>> full things fall apart:
>>
>> PERROR: Error in file write: No space left on device [in
>> lttng_consumer_on_read_subbuffer_mmap() at consumer.c:1367]
>>
>> The consumer daemon will not be able to write the metadata channel and
>> therefore the trace data set will be unusable (cannot be read with
>> babeltrace).
>>
>> -rwxrwxrwx 1 testuser users 0 Nov 16 11:22 metadata
>> -rwxrwxrwx 1 testuser users 15728640 Nov 16 11:22 myevents_0
>> -rwxrwxrwx 1 testuser users 4096 Nov 16 11:22 myevents_1
>>
>> Is it possible to somehow reserve the file size (fallocate) for metadata
>> so that in case the disk gets full at least the metadata gets written
>> and the resulting trace set is readable with babeltrace ?
>>
>> I wonder if that is possible at all. The consumer daemon doesn't know
>> upfront how much would need to be reserved for metadata, right ?
>>
>> Any ideas ?
>>
>> Thanks,
>> Paul
>>
>>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
More information about the lttng-dev
mailing list