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: [EMAIL PROTECTED] > -- Regards ----- Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
