From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH, RFC] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY Date: Wed, 7 Sep 2011 20:51:05 +0800 Message-ID: <20110907125105.GA15064@localhost> References: <20110827061409.GA6854@infradead.org> <20110827135825.GA22575@localhost> <20110903011315.GJ12182@quack.suse.cz> <20110903213527.GB10529@localhost> <20110905111153.GD5466@quack.suse.cz> <20110905132216.GB1349@localhost> <20110907115237.GA21478@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "linux-fsdevel@vger.kernel.org" , Jan Kara , "xfs@oss.sgi.com" To: Christoph Hellwig Return-path: Content-Disposition: inline In-Reply-To: <20110907115237.GA21478@infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com List-Id: linux-fsdevel.vger.kernel.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