From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Tue, 05 Dec 2006 16:50:36 -0500 Message-ID: <4575E9AC.1010706@redhat.com> 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> <4574BF52.6090600@mcs.anl.gov> <20061205170109.GP3013@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Latchesar Ionkov , Rob Ross , Christoph Hellwig , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:37475 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759050AbWLEVut (ORCPT ); Tue, 5 Dec 2006 16:50:49 -0500 To: Matthew Wilcox In-Reply-To: <20061205170109.GP3013@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Matthew Wilcox wrote: > On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote: > >> I think that the main problem is that all these file systems resove a >> path name, one directory at a time bringing the server to its knees by >> the huge amount of requests. I would like to see what the performance >> is if you a) cache the last few hundred lookups on the server side, >> and b) modify VFS and the file systems to support multi-name lookups. >> Just assume for a moment that there is no any way to get these new >> operations in (which is probaly going to be true anyway :). What other >> solutions can you think of? :) >> > > How exactly would you want a multi-name lookup to work? Are you saying > that open("/usr/share/misc/pci.ids") should ask the server "Find usr, if > you find it, find share, if you find it, find misc, if you find it, find > pci.ids"? That would be potentially very wasteful; consider mount > points, symlinks and other such effects on the namespace. You could ask > the server to do a lot of work which you then discard ... and that's not > efficient. It could be inefficient, as pointed out, but defined right, it could greatly reduce the number of over the wire trips. The client can already tell from its own namespace when a submount may be encountered, so know not to utilize the multicomponent pathname lookup facility. The requirements could state that the server stops when it encounters a non-directory/non-regular file node in the namespace. This sort of thing... ps