openg

[Christoph Hellwig <hch@infradead.org>]

On Tue, Dec 05, 2006 at 03:44:31PM -0600, Rob Ross wrote:
> The openg() really just does the lookup and permission checking). The 
> openfh() creates the file descriptor and starts that context if the 
> particular FS tracks that sort of thing.

...

> Well you've caught me. I don't want to cache the values, because I 
> fundamentally believe that sharing state between clients and servers is 
> braindead (to use Christoph's phrase) in systems of this scale 
> (thousands to tens of thousands of clients). So I don't want locks, so I 
> can't keep the cache consistent, ... So someone else will have to run 
> the tests you propose :)...

Besides the whole ugliness you miss a few points about the fundamental
architecture of the unix filesystem permission model unfortunately.

Say you want to lookup a path /foo/bar/baz, then the access permission
is based on the following things:

 - the credentials of the user.  let's only take traditional uid/gid
   for this example although credentials are much more complex these
   days
 - the kind of operation you want to perform
 - the access permission of the actual object the path points to (inode)
 - the lookup permission (x bit) for every object on the way to you object

In your proposal sutoc is a simple conversion operation, that means
openg needs to perfom all these access checks and encodes them in the
fh_t.  That means an fh_t must fundamentally be an object that is kept
in the kernel aka a capability as defined by Henry Levy.  This does imply
you _do_ need to keep state.  And because it needs kernel support you
fh_t is more or less equivalent to a file descriptor with sutoc equivalent
to a dup variant that really duplicates the backing object instead of just
the userspace index into it.

Note somewhat similar open by filehandle APIs like oben by inode number
as used by lustre or the XFS *_by_handle APIs are privilegued operations
because of exactly this problem.

What according to your mail is the most important bit in this proposal is
that you thing the filehandles should be easily shared with other system
in a cluster.  That fact is not mentioned in the actual proposal at all,
and is in fact that hardest part because of inherent statefulness of
the API.


> What's the etiquette on changing subject lines here? It might be useful 
> to separate the openg() etc. discussion from the readdirplus() etc. 
> discussion.

Changing subject lines is fine.