fixing redundant network opens on Linux file creation

[Steven French]

The creat() system call results (for the Linux kernel) in calls to create
(via vfs_create) then later a call to open (via dentry_open) both of which
eventually end up (for the cifs vfs) doing a network open of the file from
the perspective of the CIFS protocol which degrades performance (because
every creat does one additional open & close than ideal).    In the cifs
protocol file creation is handled as a flag on the open request so create
has a sideeffect of opening the file.   Unfortunately since mknod can call
vfs_create (presumably without immediately afterwards calling open), it
seems like a vfs can't assume that all creates are necessarily going to be
immediately followed by a file open (server file handle leaks would be
possible if such an assumption were made).    smbfs in effect ignores the
subsequent open and the nfs vfs doesn't have this problem because it
doesn't send a remote open request in nfs_open (since v2 and v3 nfs doesn't
really need an open file handle for file based operations like smb/cifs
does).  To improve creat() performance for cifs (without changing namei.c
itself) it seems like there are only two obvious alternatives:

1) Have the cifs vfs ignore subsequent opens of the same file (never have
more than one open per inode - ala smbfs) - which has the disadvantage of
making the open flags (and pid) incorrect for subsequent opens and would
cause server problems with handling byte range locks and potentially causes
problems with other clients accessing a file that was just created via
mknod and therefore should not be considered open anymore.

2) Have the cifs vfs do "lazy close" of files - perhaps using the original
"opbatch" distributing caching mechanism in the smb/cifs protocol (which
cached opens for optimal performance running batch files on network drives)
for distributed cache management (so the client will not cause sharing
violations if other clients try to access the same file).

I prefer the latter but am working on proving that it works now.   Any
other approaches?

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at us.ibm.com