fixing redundant network opens on Linux file creation

Richard Sharpe rsharpe at richardsharpe.com
Mon Jan 6 20:02:03 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.

While the connectathon one does that, SPECsfs does not, and we look like 
doing something similar to the SPECsfs stuff for CIFS.

Secondly, someone might do a create just to create a file and not access 
it. You can't cache that info across syscalls. Also, that is kinda what 
andXs are for. You could turn the CREAT into an OpenAndX with an immediate 
close :-)

At least it saves you one round trip, but of course, you might already be 
doing that.

The place where an intent flag can save you is with an open that passes 
O_CREAT.

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