fixing redundant network opens on Linux file creation

[Bryan Henderson]

>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.

That's really orthogonal to this discussion.  If you want to conserve the
number of VFS operation routines, you can have a single routine with
parameters for a dozen different operations whether it is
lookup-with-intent or lookup-and-do.  Pretty much the only difference in
the C code is the name of the routine.

But my discomfort with the lookup-with-intent approach is focused on the
open/create operation in particular.  From what I can tell, these intents
are more than just declaration of intent.  They're promises.  If the VFS
caller did a lookup with intent to create if not found, and then didn't
follow through on that intent, I guess that would cause trouble on Lustre
since the implementation of lookup-with-intent actually created the file.

That's not the concept of intent declaration as I've seen it everywhere
else.  Something like "open with write intent" always means either "open
the file and I won't do anything but write to it," or "open the file and
I'll probably be writing to it," but never "open the file and the next
thing you see from me will be a write of 10 bytes at offset 20."

Another thing the structure of this "intent" interface says to me is that a
filesystem driver might choose in some cases not to open the file but wait
until the open is actually requested.  If so, doesn't the filesystem driver
have to maintain some cognizance of the thread of file accesses, so it can
match up an open with a previous lookup-with-intent and know if that
particular open is already done?  That kind of state has always been
intentionally omitted from the VFS interface.