Re: fixing redundant network opens on Linux file creation

[Jan Hudec <bulb@ucw.cz>]

On Mon, Jan 06, 2003 at 10:14:10AM -0800, Richard Sharpe wrote:
> 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? 

I am not sure, what it means "legacy call", but I am pretty sure, that
creat and open(... O_CREAT) end up calling exactly the same filesystem
methods with exactly the same parameters. (First lookup is called and it
does not know, what is to happen to the file, then create is called and
it does not know open mode for the file and last open is called with
apropriate mode).

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

There is a lookup intent patch from lustre group. It can be found
somewhere in the archives. Pushing that (or something along that lines)
to mainline and using that would be IMHO most beneficial (because all
networking filesystems could benefit from this patch). However that does
not fall into the category "not changing namei.c".

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>