From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Wed, 29 Nov 2006 12:39:13 +0000 Message-ID: <20061129123913.GA15994@infradead.org> References: <6.2.3.4.2.20061127213243.04f786c0@cic-mail.lanl.gov> <20061128055428.GA29891@infradead.org> <20061129090450.GA16296@infradead.org> <20061129122313.GG14315@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:58329 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S967172AbWK2MjQ (ORCPT ); Wed, 29 Nov 2006 07:39:16 -0500 To: Matthew Wilcox Content-Disposition: inline In-Reply-To: <20061129122313.GG14315@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Nov 29, 2006 at 05:23:13AM -0700, Matthew Wilcox wrote: > Is this for people who don't know about dup(), or do they need > independent file offsets? If the latter, I think an xdup() would be > preferable (would there be a security issue for OSes with revoke()?) > Either that, or make the key be useful for something else. Not sharing the file offset means we need a separate file struct, at which point the only thing saved is doing a lookup at the time of opening the file. While a full pathname traversal can be quite costly an open is not something you do all that often anyway. And if you really need to open/close files very often you can speed it up nicely by keeping a file descriptor on the parent directory open and use openat(). Anyway, enough of talking here. We really need a very good description of the use case people want this for, and the specific performance problems they see to find a solution. And the solution definitly does not involve as second half-assed file handle time with unspecified lifetime rules :-)