On Wed, 2012-11-28 at 21:59 +0100, Piotr Szymaniak wrote: > On Wed, Nov 28, 2012 at 06:39:20PM +0400, Vyacheslav Dubeyko wrote: > > On Wed, 2012-11-28 at 15:21 +0100, Piotr Szymaniak wrote: > > > On Tue, Nov 27, 2012 at 08:43:01PM +0300, Vyacheslav Dubeyko wrote: > > > > Could you describe the path of issue reproducing? What filesystem > > > > operations took place near before the issue? > > > > > > Reproduce: Use a computer with nilfs2? No idea... I notice this issue > > > from time to time. I suppose it's more visible when the system is idle > > > and then I notice a lot of CPU load without any reason (also as I wrote > > > before - it stops immediately after runnig sync). > > > > > > > Ok. Could you share output of "top" and "ps ax" for the case of issue > > reproducing? These outputs can be helpful for beginning of analysis. > > Already attached [1] "ps ax" output before. Don't know if top can get > something usefull here, but I can try to "catch" it. > > [1] http://www.spinics.net/lists/linux-nilfs/msg01481.html > Thank you. I think that it needs to use such tools for the issue investigation: 1. echo t > /proc/sysrq-trigger should tell us what the flusher is doing. 2. The /proc/meminfo and /proc/sys/vm/dirty_ratio output for the issue time can be also helpful. 3. It makes sense to use blktrace for getting I/O traces during flushing during sync command execution and near before issue was occurred. I/O traces can be useful for analysis but this output can contain huge info amount. So, I think first of all it needs to get info about what flusher doing during eating CPU time. With the best regards, Vyacheslav Dubeyko. > Piotr Szymaniak. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
