Re: Strange "flush" process bahaviour

[Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html