From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Kleikamp Subject: Re: Race between __sync_single_inode() and LogFS garbage collector Date: Mon, 19 Feb 2007 21:06:33 -0600 Message-ID: <1171940793.7963.10.camel@kleikamp.austin.ibm.com> References: <20070219213150.GD7813@lazybastard.org> <1171926356.9771.34.camel@kleikamp.austin.ibm.com> <20070219232351.GG7813@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: =?ISO-8859-1?Q?J=F6rn?= Engel Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:55574 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965613AbXBTDGg (ORCPT ); Mon, 19 Feb 2007 22:06:36 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1K36ZxI010597 for ; Mon, 19 Feb 2007 22:06:35 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1K36ZIm530338 for ; Mon, 19 Feb 2007 20:06:35 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1K36ZTn007370 for ; Mon, 19 Feb 2007 20:06:35 -0700 In-Reply-To: <20070219232351.GG7813@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 2007-02-19 at 23:23 +0000, J=F6rn Engel wrote: > On Mon, 19 February 2007 17:05:55 -0600, Dave Kleikamp wrote: > >=20 > > It'd be nice if you could drop s_w_mutex when the garbage collector > > calls i_get(). >=20 > Not possible. Garbage collection only happens when space is getting > tight. At that moment all writes must be serialized or this race wil= l > be the least of my problems. :( >=20 > > Otherwise, you may be able to call ilookup5_nowait() in the garbage > > collector, and skip that inode if I_LOCK is set. >=20 > 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 an= d > 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 spit= e > 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. >=20 > J=F6rn >=20 --=20 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