Re: Race between __sync_single_inode() and LogFS garbage collector

[Dave Kleikamp <shaggy@linux.vnet.ibm.com>]

On Mon, 2007-02-19 at 23:23 +0000, Jörn Engel wrote:
> On Mon, 19 February 2007 17:05:55 -0600, Dave Kleikamp wrote:
> > 
> > It'd be nice if you could drop s_w_mutex when the garbage collector
> > calls i_get().
> 
> Not possible.  Garbage collection only happens when space is getting
> tight.  At that moment all writes must be serialized or this race will
> be the least of my problems. :(
> 
> > Otherwise, you may be able to call ilookup5_nowait() in the garbage
> > collector, and skip that inode if I_LOCK is set.
> 
> Also not possible.  I cannot skip that inode, or again this race will be
> a minor problem.  The inode exists on the medium and I must get it by
> some means.  Re-reading it from the medium is fine, writing is not and
> waiting for the write to happen brings me back to square one.

Okay, I get it now.  You've got more constraints than I initially
realized.

> It is a nasty problem that has been haunting me for about a year now.
> For a while I tried ilookup5_nowait() and just used the inode in spite
> of the lock.  But that will explode spectacularly when racing against
> generic_drop_inode().

You've obviously given this a lot more thought that I have, but this
sounds like something that has possibilities.  You couldn't implement
your own drop_inode method that does better locking against the garbage
collector?

> Double-caching or a common lock seem to be the only solutions.
> 
> Jörn
> 
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html