Re: openg and path_to_handle

[Matthew Wilcox <matthew@wil.cx>]

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.