On Wed, 25 Mar 2009 10:50:37 +0800 Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: > > Given the right situation though (or maybe the right filesystem), it's > > not too hard to imagine this problem occurring even in current mainline > > code with an inode that's frequently being redirtied. > > My reasoning with recent kernel is: for kupdate, s_dirty enqueues only > happen in __mark_inode_dirty() and redirty_tail(). Newly dirtied > inodes will be parked in s_dirty for 30s. During which time the > actively being-redirtied inodes, if their dirtied_when is an old stuck > value, will be retried for writeback and then re-inserted into a > non-empty s_dirty queue and have their dirtied_when refreshed. > Doesn't that assume that there are new inodes that are being dirtied? If you only have the same inodes being redirtied and never any new ones, the problem still occurs, right? > > > > > > ...I see no obvious reasons against unconditionally resetting dirtied_when. > > > > > > (a) Delaying an inode's writeback for 30s maybe too long - its blocking > > > condition may well go away within 1s. (b) And it would be very undesirable > > > if one big file is repeatedly redirtied hence its writeback being > > > delayed considerably. > > > > > > However, redirty_tail() currently only tries to speedup writeback-after-redirty > > > in a _best effort_ way. It at best partially hides the above issues, > > > if there are any. In particular, if (b) is possible, the bug should > > > already show up at least in some situations. > > > > > > For XFS, immediately sync of redirtied inode is actually discouraged: > > > > > > http://lkml.org/lkml/2008/1/16/491 > > > > > > > > > > Ok, those are good points that I need to think about. > > > > Thanks for the help so far. I'd welcome any suggestions you have on > > how best to fix this. > > For NFS, is it desirable to retry a redirtied inode after 30s, or > after a shorter 5s, or after 0.1~5s? Or the exact timing simply > doesn't matter? > I don't really consider NFS to be a special case here. It just happens to be where we saw the problem originally. Some of its characteristics might make it easier to hit this, but I'm not certain of that. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
