Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751991Ab0GHEbK (ORCPT ); Thu, 8 Jul 2010 00:31:10 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:49041 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750810Ab0GHEbI convert rfc822-to-8bit (ORCPT ); Thu, 8 Jul 2010 00:31:08 -0400 Subject: Re: [PATCH -V14 0/11] Generic name to handle and open by handle syscalls Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Andreas Dilger In-Reply-To: <20100707180507.GE9263@laptop> Date: Wed, 7 Jul 2010 17:49:50 -0600 Cc: "J. Bruce Fields" , "Aneesh Kumar K. V" , Neil Brown , Christoph Hellwig , "viro@zeniv.linux.org.uk Viro" , "corbet@lwn.net Corbet" , "hooanon05@yahoo.co.jp Okajima" , linux-fsdevel@vger.kernel.org, "sfrench@us.ibm.com French" , "philippe.deniel@CEA.FR Deniel" , "linux-kernel@vger.kernel.org Mailinglist" Content-Transfer-Encoding: 8BIT Message-Id: References: <1276621981-2774-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <871vbn2mk9.fsf@linux.vnet.ibm.com> <20100702064108.64034561@notabene.brown> <87iq4y29a6.fsf@linux.vnet.ibm.com> <20100706161002.GD7387@fieldses.org> <87eifgfsez.fsf@linux.vnet.ibm.com> <2DC68584-15A8-4C48-8E65-E7EF1DCEEAD0@oracle.com> <20100707150535.GB24360@fieldses.org> <5920F408-E923-4467-A6A9-6C0923C00927@oracle.com> <20100707180507.GE9263@laptop> To: Nick Piggin X-Mailer: Apple Mail (2.1078) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C355471.017C:SCFMA4539814,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1486 Lines: 27 On 2010-07-07, at 12:05, Nick Piggin wrote: > On Wed, Jul 07, 2010 at 11:02:47AM -0600, Andreas Dilger wrote: >> I think you are assuming too much about the use of the file handle. What I'm interested in is not a userspace file server, but rather a more efficient way to have 10000's to millions of clients to be able to open the same regular file, without having to do full path traversal for each one. > > Really? What kind of clients? What sort of speedups do you hope to see? > Path traversal can get vastly cheaper in both single threaded and parallel > cases with my locking changes. This is for Lustre clients, but really any kind of network filesystem is equally affected. This isn't really an issue of the local dcache performance, but rather network latency for each component of the path traversal, and for a large number of clients the metadata server is the bottleneck for doing the traversal. > It is not acceptable to work around fixable deficiencies in our critical > infrastructure like path walking with hacks like this. If path walking > is still much too expensive, that's another story... Two different problems, I'm afraid. Cheers, Andreas -- Andreas Dilger Lustre Technical Lead Oracle Corporation Canada Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/