From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: openg and path_to_handle Date: Thu, 14 Dec 2006 14:20:49 -0700 Message-ID: <20061214212049.GT21070@parisc-linux.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Latchesar Ionkov , David Chinner , Christoph Hellwig , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:47798 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932945AbWLNVqB (ORCPT ); Thu, 14 Dec 2006 16:46:01 -0500 To: Rob Ross Content-Disposition: inline In-Reply-To: <4581BB79.4070201@mcs.anl.gov> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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. 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.