Re: [patch] fix periodic superblock dirty inode flushing

[Fengguang Wu <fengguang.wu@gmail.com>]

On Wed, Jul 18, 2007 at 08:10:18PM -0700, Andrew Morton wrote:
> On Thu, 19 Jul 2007 10:59:27 +0800 Fengguang Wu <fengguang.wu@gmail.com> wrote:
> > On Mon, Jul 16, 2007 at 05:01:31PM -0700, Ken Chen wrote:
> > > I ran some more tests over the weekend with the debug turned on. There
> > > are a few fall out that the order-ness of sb-s_dirty is corrupted.  We
> > > probably should drop this patch until I figure out a real solution to
> > > this.
> > > 
> > > One idea is to use rb-tree for sorting and use a in-tree dummy node as
> > > a tree iterator.  Do you think that will work better?  I will hack on
> > > that.
> > 
> > Sorry if I'm not backgrounded.
> > 
> > But what's the problem of a list? If we always do the two actions
> > *together*:
> >         1) update inode->dirtied_when
> >         2) requeue inode in the correct place
> > the list will be in order.
> > linux-2.6.22-rc6-mm1/fs/fs-writeback.c obviously obeys this rule.
> > 
> > I don't see how can a new data structure make life easier.
> > 1) and 2) should still be safeguarded, isn't it?
> 
> Well yes, the existing implementation does its best to work, and almost
> does work correctly but it was really hard to do and it is hard to maintain.
> 
> Whereas if we had a better data structure it would be cleaner and easier to
> implement and to maintain, I expect.
>
> With an indexed data structure (ie: radix-tree or rbtree) the writeback
> code can remember where it was up to in the ordered list of inodes so it
> can drop locks, do writeback, remember where it was up to for the next
> pass, etc.
> 
> Basically, the walk of the per-superblock inodes would follow the same
> model as the walk of the per-inode pages.  And the latter has worked out
> *really* well.  It would be great if the per-sb inode traversal was as
> flexible and as powerful as the page walks.
> 
> Probably it never will be, because I suspect we'd need to order the inodes
> by multiple indices.  I hn't thought it through, really.  

Just one more possibility...  an array of lists?

The array is cyclic and time-addressable, and
the lists can be ordered by other criterion(s).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>