fixing redundant network opens on Linux file creation
adilger at clusterfs.com
Mon Jan 6 22:50:00 GMT 2003
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
The reason we still do a VFS open call after we do the lookup-with-intent
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 ;-).
More information about the samba-technical