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 [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
