[Top] [All Lists]

Re: [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed t

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY
From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
Date: Wed, 7 Sep 2011 20:51:05 +0800
Cc: Jan Kara <jack@xxxxxxx>, "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>
In-reply-to: <20110907115237.GA21478@xxxxxxxxxxxxx>
References: <20110827061409.GA6854@xxxxxxxxxxxxx> <20110827135825.GA22575@localhost> <20110903011315.GJ12182@xxxxxxxxxxxxx> <20110903213527.GB10529@localhost> <20110905111153.GD5466@xxxxxxxxxxxxx> <20110905132216.GB1349@localhost> <20110907115237.GA21478@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
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?


<Prev in Thread] Current Thread [Next in Thread>