From: Christoph Hellwig <hch@infradead.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY
Date: Wed, 7 Sep 2011 07:52:37 -0400 [thread overview]
Message-ID: <20110907115237.GA21478@infradead.org> (raw)
In-Reply-To: <20110905132216.GB1349@localhost>
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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"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 07:52:37 -0400 [thread overview]
Message-ID: <20110907115237.GA21478@infradead.org> (raw)
In-Reply-To: <20110905132216.GB1349@localhost>
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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-07 11:52 UTC|newest]
Thread overview: 17+ 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 6:14 ` Christoph Hellwig
2011-08-27 13:58 ` Wu Fengguang
2011-08-27 13:58 ` Wu Fengguang
2011-09-03 1:13 ` Jan Kara
2011-09-03 1:13 ` Jan Kara
2011-09-03 21:35 ` Wu Fengguang
2011-09-03 21:35 ` Wu Fengguang
2011-09-05 11:11 ` Jan Kara
2011-09-05 11:11 ` Jan Kara
2011-09-05 13:22 ` Wu Fengguang
2011-09-05 13:22 ` Wu Fengguang
2011-09-07 11:52 ` Christoph Hellwig [this message]
2011-09-07 11:52 ` Christoph Hellwig
2011-09-07 12:51 ` Wu Fengguang
2011-09-08 0:51 ` Jan Kara
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=20110907115237.GA21478@infradead.org \
--to=hch@infradead.org \
--cc=fengguang.wu@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
/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.