From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: openg and path_to_handle Date: Thu, 14 Dec 2006 17:02:45 -0600 Message-ID: <4581D815.5070400@mcs.anl.gov> References: <20061129122313.GG14315@parisc-linux.org> <20061129123913.GA15994@infradead.org> <4570ACD1.7060800@mcs.anl.gov> <4574BF52.6090600@mcs.anl.gov> <20061206094805.GB33919298@melbourne.sgi.com> <4576E783.7020402@mcs.anl.gov> <4581BB79.4070201@mcs.anl.gov> <20061214212049.GT21070@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Latchesar Ionkov , David Chinner , Christoph Hellwig , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:38597 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751660AbWLNXDA (ORCPT ); Thu, 14 Dec 2006 18:03:00 -0500 To: Matthew Wilcox In-Reply-To: <20061214212049.GT21070@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Matthew Wilcox wrote: > On Thu, Dec 14, 2006 at 03:00:41PM -0600, Rob Ross wrote: >> I don't think that I understand what you're saying here. The openg() >> call does not perform file open (not that that is necessarily even a >> first-class FS operation), it simply does the lookup. >> >> When we were naming these calls, from a POSIX consistency perspective it >> seemed best to keep the "open" nomenclature. That seems to be confusing >> to some. Perhaps we should rename the function "lookup" or something >> similar, to help keep from giving the wrong idea? >> >> There is a difference between the openg() and path_to_handle() approach >> in that we do permission checking at openg(), and that does have >> implications on how the handle might be stored and such. That's being >> discussed in a separate thread. > > I was just thinking about how one might implement this, when it struck > me ... how much more efficient is a kernel implementation compared to: > > int openg(const char *path) > { > char *s; > do { > s = tempnam(FSROOT, ".sutoc"); > link(path, s); > } while (errno == EEXIST); > > mpi_broadcast(s); > sleep(10); > unlink(s); > } > > and sutoc() becomes simply open(). Now you have a name that's quick to > open (if a client has the filesystem mounted, it has a handle for the > root already), has a defined lifespan, has minimal permission checking, > and doesn't require standardisation. > > I suppose some cluster fs' might not support cross-directory links > (AFS is one, I think), but then, no cluster fs's support openg/sutoc. Well at least one does :). > If a filesystem's willing to add support for these handles, it shouldn't > be too hard for them to treat files starting ".sutoc" specially, and as > efficiently as adding the openg/sutoc concept. Adding atomic reference count updating on file metadata so that we can have cross-directory links is not necessarily easier than supporting openg/openfh, and supporting cross-directory links precludes certain metadata organizations, such as the ones being used in Ceph (as I understand it). This also still forces all clients to read a directory and for N permission checking operations to be performed. I don't see what the FS could do to eliminate those operations given what you've described. Am I missing something? Also this looks too much like sillyrename, and that's hard to swallow... Regards, Rob