fixing redundant network opens on Linux file creation

[Richard Sharpe]

On Mon, 6 Jan 2003, Steven French wrote:

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

Isn't creat() a legacy call? I have never used it, and use open(..., 
O_CREAT,...) instead.

Isn't this just a cost of using legacy calls? Why complicate things overly 
for a call that might not be used all that much? 
 
> 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
> 

-- 
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com