fixing redundant network opens on Linux file creation

[Andreas Dilger]

On Jan 06, 2003  14:23 -0800, Bryan Henderson wrote:
> >In our code, the lookup-with-intent actually performs both of the
> >operations on the server,
> 
> What I don't get is why is the concept of "intent" even involved here?  If
> lookup-with-intent does the lookup and open (and, I guess, create where
> appropriate), why don't you call it "lookup-and-open" and then skip the
> subsequent VFS open call?

Because the intent code is much more than just "lookup-and-open".
It is also lookup-and-create, lookup-and-mkdir, lookup-and-unlink,
lookup-and-setattr, etc.  I don't think we want separate VFS ops for
every possible VFS op.

Also, in the Linux VFS, the lookup call is the one which is actually
doing the locking on the appropriate objects for atomicity purposes,
which is actually the critical thing here - we use lookup2 for doing
the distributed locking as much as for the RPC savings.

Like another Lustre developer remarked "it's a lock-with-intent on the
wire, and a lookup-with-intent in the kernel".

> You also mention the distributed version of the Lustre lookup-with-intent:
> 
> >OR it returns a lock to the client that grants the client exclusive
> >   control over the item(s) in question (normally the parent dir(s)) and
> >   lets the client do the operations locally and send the operations to
> >   the server separately.
> 
> and the same question applies in that case.  While the client may do the
> open separately, there's no reason it shouldn't do it before returning from
> the VFS lookup-with-intent call, which means it would be simpler as a
> lookup-and-open.

The reason we still do a VFS open call after we do the lookup-with-intent
are several:
1) like I said above, we don't want to have 2x every VFS op (one with
   lookup and another without) either in our code or in the VFS proper
2) the amount of changes needed to the VFS would be quite large, if it had
   to determine whether it should do a lookup-with-intent and no regular
   op, or the lookup + regular op
3) doing lookup-with-intent allows us to manage the locking internal to
   the filesystem however we want instead of having to live within the
   VFS's ideas of locking (e.g. we could split up the locks within a
   single directory so you could do concurrent creates/renames/unlinks
   in a single directory if we so choose, and we may).

The thing to focus on here is that lookup2 is as much a locking API as
it is a lookup+operation API.  I was thinking a clever name for it would
be "loockup", but that has some unfortunate connotations ;-).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/