fixing redundant network opens on Linux file creation

Richard Sharpe rsharpe at richardsharpe.com
Mon Jan 6 18:57:00 GMT 2003


On Mon, 6 Jan 2003, Steven French wrote:

> On Mon, Jan 06, 2003 at 10:14:10AM -0800, Richard Sharpe wrote:
> >
> > 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?
> 
> As Jan indicated, it looks like creat(filename,mode) and open(filename,
> O_CREAT | O_TRUNC, mode) follow similar paths in the Linux kernel and both
> have the potential "redundant" network file open problem.   In addition the
> Connectathon "nfs" (posix file API compliance) tests do issue the creat()
> call (a lot) so it is hard to avoid whether even if some considered it
> legacy baggage.    Although it would make sense intuitively that passing
> O_CREAT on the open system call would (only) invoke the vfs open call (with
> the O_CREAT) flag - it first seems to call the vfs create call (and then
> invoke open later with the O_CREAT flag set) and the obvious idea of simply
> having some network filesystems simply not exporting a create vfs entry
> point would result in EACCES being returned (rather than the vfs invoking
> the filesystem's open routine specifying the O_CREAT flag as one might
> expect).   Uggh.
> 
> I too am intrigued about the idea of a "lookup intent" change and better
> optimizing the namei.c/open.c file creation code path for this common case
> but I didn't see a quick, low risk (for 2.5 kernel) change that would help
> network filesystems so am toying with "opbatch/lazy close" ideas.

FreeBSD has an intent 'flag' on the name cache routines, and I think this 
intent is passed to the VOP (VFS VNODE) calls as well, so that a network 
file system can do the right things ... I will have to look.

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




More information about the samba-technical mailing list