http://bugzilla.opensuse.org/show_bug.cgi?id=1021307
http://bugzilla.opensuse.org/show_bug.cgi?id=1021307#c10
Mel Gorman
@Mel, do you have an idea how this could be traced without interfering with the timings of journald ?
sudo perf -a trace -e fdatasync,fsync,msync,sync,sync_file_range,syncfs While that's running it'll track all sync-related syscalls globally. If you want to target journald, you'll need to specify the pid with -p. Hit ctrl-c when you're done and there should be a breakdown of the sync calls. Crude example of tracing like this # dd if=/dev/zero of=zerofile ibs=1048576 count=500; sudo perf trace -e fdatasync,fsync,msync,sync,sync_file_range,syncfs sync; rm zerofile 500+0 records in 1024000+0 records out 524288000 bytes (524 MB, 500 MiB) copied, 0.772471 s, 679 MB/s 1023.708 (1023.708 ms): sync/24234 sync( ) = 0 That is showing that the sync command after an async dd took 1023.708 ms to complete. You can monitor indefinitely by specifying no command or record for a duration by running "sleep X" where X is the number of seconds you want to record data for.
It might be possible by using perf or do you think strace should be enough for this case ?
perf can do it with lower interference. If there are a high number of sync calls then you may need to increase the mmap space with -m to avoid lost events. The same can be achieved with strace but you specified that the interference with journald be minimised and strace is very heavy -- You are receiving this mail because: You are on the CC list for the bug.