Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992914AbbEOXtn (ORCPT ); Fri, 15 May 2015 19:49:43 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:58583 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2992702AbbEOXtk (ORCPT ); Fri, 15 May 2015 19:49:40 -0400 Date: Sat, 16 May 2015 00:49:36 +0100 From: Al Viro To: NeilBrown Cc: Andreas Dilger , Dave Chinner , Linus Torvalds , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks Message-ID: <20150515234936.GK7232@ZenIV.linux.org.uk> References: <20150505052205.GS889@ZenIV.linux.org.uk> <20150511180650.GA4147@ZenIV.linux.org.uk> <20150513222533.GA24192@ZenIV.linux.org.uk> <20150514033040.GF7232@ZenIV.linux.org.uk> <20150514112304.GT15721@dastard> <20150516093022.51e1464e@notabene.brown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150516093022.51e1464e@notabene.brown> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1708 Lines: 32 On Sat, May 16, 2015 at 09:30:22AM +1000, NeilBrown wrote: > .. and I've been wondering what to do about i_mutex and NFS. I've had > customer reports of slowness in creating files that seems to be due to > i_mutex on the directory being held over the whole 'create' RPC, so only one > of those can be in flight at the one time. > "make -j" on a large source directory can easily want to create lots of > "*.o" files at "the same time". > > And NFS doesn't need i_mutex at all because the server will provide the > needed guarantees. Directory i_mutex is used for a lot more than serialization of fs methods on said directory - a lot of dcache handling relies upon having it held around adding dentries/moving them around/making them negative/etc. Server can't do a damn thing about those, obviously. Neither can it do anything about multiple lookups on the same name in the same directory, just because several processes have arrived at the same time with dcache cold. And no, caching dentry before the end of lookup isn't a good idea either - you'll get tons of messy corner cases. If anyone has a usable finer-grained locking scheme, I would _love_ to see it. All I'd seen from Lustre folks in that area was bringing Stross' mythos to mind - both as in "reduction of NP to P would be handy for analysis" and "looking into that thing feels like an excellent way of inviting the gibbering monstrosities from beyond the spacetime to chew on your cortex". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/