Re: [PATCH] writeback: reset inode dirty time when adding it back to empty s_dirty list

[Jeff Layton <jlayton@redhat.com>]

On Wed, 25 Mar 2009 10:50:37 +0800
Wu Fengguang <fengguang.wu@intel.com> 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@redhat.com>