Re: Reclaiming vnodes

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Wed Sep 23 2009 at 09:40:26 -0700, Bill Stouder-Studenmund wrote:
> > But vnodes doesn't need to be reclaimed so often as allocated. I think  
> > that allocation is more critical then  speed of reclaim.
> 
> Huh? After we reach the max # of vnodes, every allocated vnode comes from 
> a vnode being cleaned.
> 
> Also, since you have one thread, what happens when one file system is slow 
> about reclaiming a vnode? Say an nfs mount that's having problems. Or a 
> disk array that is having a lot of i/o errors that take a while but which 
> it's recovering from. Your one thread now stalls, and so you can starve 
> the whole OS of vnodes.

With the patch vnodes are vnalloc()'d always.  So you're not starving
the OS of vnodes ...

I think it's becoming very clear that the proposed change is not
acceptable in the grand scheme of things and debating details will not
change this.

The major advantages of the current scheme are:

  * as Bill reminded us, isolating damage from flimsy file systems and/or
    media to single threads instead of the entire system
  * some sort of control on the maximum amount of vnodes consumed by vfs
  * determinism from synchronous vnode reclaiming
    (although, I have to admit this might be of questionable value,
    since it's not synchronous wrt to actual use of the vnode)

benefits of the new model:

  * allows zfs to work better, although does not completely address the
    deadlock in low-memory situations
    (how much does this matter in practise and under what type of
    load, nobody knows)


I think Bill's proposal was constructive and a good way to move forward
and get zfs working while waiting for major zfs or vfs restructuring.
However, I'm not sure about the details of the deadlock and if it's
not a simple locking-against-myself, how expensive would detecting it
between multiple threads be?