From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Latchesar Ionkov" Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Fri, 1 Dec 2006 19:35:01 -0700 Message-ID: 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> <20061129123913.GA15994@infradead.org> <4570ACD1.7060800@mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Christoph Hellwig" , "Matthew Wilcox" , "Gary Grider" , linux-fsdevel@vger.kernel.org Return-path: Received: from nf-out-0910.google.com ([64.233.182.184]:3453 "EHLO nf-out-0910.google.com") by vger.kernel.org with ESMTP id S1162727AbWLBCfD (ORCPT ); Fri, 1 Dec 2006 21:35:03 -0500 Received: by nf-out-0910.google.com with SMTP id o25so3715249nfa for ; Fri, 01 Dec 2006 18:35:02 -0800 (PST) To: "Rob Ross" In-Reply-To: <4570ACD1.7060800@mcs.anl.gov> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, One general remark: I don't think it is feasible to add new system calls every time somebody has a problem. Usually there are (may be not that good) solutions that don't require big changes and work well enough. "Let's change the interface and make the life of many filesystem developers miserable, because they have to worry about 3-4-5 more operations" is not the easiest solution in the long run. On 12/1/06, Rob Ross wrote: > Hi all, > > The use model for openg() and openfh() (renamed sutoc()) is n processes > spread across a large cluster simultaneously opening a file. The > challenge is to avoid to the greatest extent possible incurring O(n) FS > interactions. To do that we need to allow actions of one process to be > reused by other processes on other OS instances. > > The openg() call allows one process to perform name resolution, which is > often the most expensive part of this use model. Because permission If the name resolution is the most expensive part, why not implement just the name lookup part and call it "lookup" instead of "openg". Or even better, make NFS to resolve multiple names with a single request. If the NFS server caches the last few name lookups, the responses from the other nodes will be fast, and you will get your file descriptor with two instead of the proposed one request. The performance could be just good enough without introducing any new functions and file handles. Thanks, Lucho