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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
