Re: openg and path_to_handle

[Rob Ross <rross@mcs.anl.gov>]

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