From: Dave Chinner <david@fromorbit.com>
To: Denys Fedorysychenko <nuclearcat@nuclearcat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: endless sync on bdi_sched_wait()? 2.6.33.1
Date: Thu, 1 Apr 2010 22:13:57 +1100 [thread overview]
Message-ID: <20100401111357.GA6601@dastard> (raw)
In-Reply-To: <201004011342.42467.nuclearcat@nuclearcat.com>
On Thu, Apr 01, 2010 at 01:42:42PM +0300, Denys Fedorysychenko wrote:
> Thats correct, it is quite busy cache server.
>
> Well, if i stop squid(cache) sync will finish enough fast.
> If i don't - it took more than hour. Actually i left that PC after 1 hour, and
> it didn't finish yet. I don't think it is normal.
> Probably sync taking new data and trying to flush it too, and till he finish
> that, more data comes.
> Actually all what i need - to sync config directory. I cannot use fsync,
> because it is multiple files opened before by other processes, and sync is
> doing trick like this. I got dead process, and only fast way to recover system
> - kill the cache process, so I/O pumping will stop for a while, and sync()
> will have chance to finish.
> Sure there is way just to "remount" config partition to ro, but i guess just
> sync must flush only current buffer cache pages.
>
> I will do more tests now and will give exact numbers, how much time it needs
> with running squid and if i kill it shortly after running sync.
Ok. What would be interesting is regular output from /proc/meminfo
to see how the dirty memory is changing over the time the sync is
running....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-04-01 11:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 16:07 endless sync on bdi_sched_wait()? 2.6.33.1 Denys Fedorysychenko
2010-03-31 22:12 ` Dave Chinner
2010-04-01 10:42 ` Denys Fedorysychenko
2010-04-01 11:13 ` Dave Chinner [this message]
2010-04-01 20:14 ` Jeff Moyer
2010-04-08 9:28 ` Jan Kara
2010-04-08 10:12 ` Denys Fedorysychenko
2010-04-12 0:47 ` Dave Chinner
2010-04-19 1:37 ` Dave Chinner
2010-04-19 7:04 ` Dave Chinner
2010-04-19 7:23 ` Dave Chinner
2010-04-21 0:33 ` Jan Kara
2010-04-21 1:54 ` Dave Chinner
2010-04-21 13:27 ` Jan Kara
2010-04-22 0:06 ` Dave Chinner
2010-04-22 12:48 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100401111357.GA6601@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuclearcat@nuclearcat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.