From: Wu Fengguang <fengguang.wu@intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>, "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY
Date: Wed, 7 Sep 2011 20:51:05 +0800 [thread overview]
Message-ID: <20110907125105.GA15064@localhost> (raw)
In-Reply-To: <20110907115237.GA21478@infradead.org>
On Wed, Sep 07, 2011 at 07:52:37PM +0800, Christoph Hellwig wrote:
> On Mon, Sep 05, 2011 at 09:22:16PM +0800, Wu Fengguang wrote:
> > > > That's a reasonable robust option, however at the cost of keeping the
> > > > writeback code in some ambiguous state ;)
> > > What do you exactly mean by ambiguous state?
> >
> > I mean in Christoph's case, it will be calling requeue_io() and at the
> > same time rely on your suggested unconditional sleep at the end of
> > wb_writeback() loop to avoid busy loop. Or in other words, b_more_io
> > will be holding both inodes that should be busy retried and the inodes
> > to be opportunistically retried. However I admit it's not a big
> > problem if we take b_more_io as general "to be retried ASAP".
> >
> > > I don't see anything ambiguous in waiting for a jiffie or so. Not
> > > that I'd be completely happy about "just wait for a while and see if
> > > things are better" but your solution does not seem ideal either...
> >
> > There are no big differences (that matter) in terms of "how much exact
> > time to wait" in this XFS case. What make me prefer b_more_io_wait is
> > that it looks a more general solution to replace the majority
> > redirty_tail() calls to avoid modifying dirtied_when.
>
> FYI, we had a few more users hit this issue recently. I'm not sure why,
> but we are seeing this fairly often now. I'd really like to get some
> sort of fix for this in ASAP as it causes data loss for users.
Jan, do you agree to push the b_more_io_wait patch into linux-next?
If not, let's do a patch to do unconditional sleep at the end of the
wb_writeback() loop?
Thanks,
Fengguang
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-07 12:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-27 6:14 [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY Christoph Hellwig
2011-08-27 13:58 ` Wu Fengguang
2011-09-03 1:13 ` Jan Kara
2011-09-03 21:35 ` Wu Fengguang
2011-09-05 11:11 ` Jan Kara
2011-09-05 13:22 ` Wu Fengguang
2011-09-07 11:52 ` Christoph Hellwig
2011-09-07 12:51 ` Wu Fengguang [this message]
2011-09-08 0:51 ` 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=20110907125105.GA15064@localhost \
--to=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).