From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: fixing redundant network opens on Linux file creation Date: Mon, 6 Jan 2003 14:56:14 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030106195614.GA688@ravel.coda.cs.cmu.edu> References: <20030106175958.GA632@vagabond> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from jaharkes by ravel.coda.cs.cmu.edu with local (Exim 3.36 #1 (Debian)) id 18VdM6-0000Co-00 for ; Mon, 06 Jan 2003 14:56:14 -0500 To: linux-fsdevel@vger.kernel.org Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org On Mon, Jan 06, 2003 at 11:42:26AM -0800, Bryan Henderson wrote: > >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 > > Better still would be to add a "create-and-open" VFS call and have namei > use it. This solves a number of problems, including the fact that it is > impossible to correctly implement an exclusive create and open with a > shared filesystem (because between when Linux confirms that the file > doesn't exist and when Linux does the VFS create, another system may have > created the file). But create is a directory operation, while open is an operation on a file. It is just a matter of convenience that open(..., O_CREAT) happens to create the directory entry if it doesn't yet exist. Logically they shouldn't be combined. Perhaps having the exclusive create lock the object and pass that info on to the associated open. In Coda these objects are named 'virgin files'. And they have some special properties, such as being able to write to a file you were allowed to create even when the ACL's are set so that you have no write permission. I sometimes wish that file creation would have been done the other way around. - Open/create a new, unnamed object, which gives a file handle. - Link this open handle into the filesystem's namespace. That way the application can lock the object, or write the data to it, etc. before making it visible to the world. Might have solved some of the possible inconsistencies for networked filesystems and is probably more resiliant wrt. symlink attacks. Jan