Return-Path: Received: from mx2.netapp.com ([216.240.18.37]:1220 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108Ab1CPNuG convert rfc822-to-8bit (ORCPT ); Wed, 16 Mar 2011 09:50:06 -0400 Subject: RE: Use of READDIRPLUS on large directories From: Trond Myklebust To: peter.staubach@emc.com Cc: neilb@suse.de, bjschuma@netapp.com, linux-nfs@vger.kernel.org In-Reply-To: <5E6794FC7B8FCA41A704019BE3C70E8B068397B4@MX31A.corp.emc.com> References: <20110316155528.31913c58@notabene.brown> <5E6794FC7B8FCA41A704019BE3C70E8B068397B4@MX31A.corp.emc.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Mar 2011 09:50:04 -0400 Message-ID: <1300283404.16266.41.camel@lade.trondhjem.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Wed, 2011-03-16 at 08:30 -0400, peter.staubach@emc.com wrote: > Perhaps the use of a heuristic that enables readdirplus only after the application has shown that it is interested in the attributes for each entry in the directory? Thus, if the application does readdir()/stat()/stat()/stat()/readdir()/... then the NFS client could use readdirplus to fill the caches. If the application is just reading the directory and looking at the names, then the client could just use readdir. > > ps Yes, possibly. The thing that convinced me that we should get rid of the limit was when Bryan was testing directories with 10^6 entries, and was seeing an order of magnitude improvement when comparing readdirplus vs. readdir on 'ls -l' workloads. I wish he had published the actual numbers in the changelog. As I recall, the slowdown when comparing readdirplus vs readdir on 'ls' workloads was far less. You can easily test that yourself, using the "-onordirplus" mount option to turn off readdirplus (which, btw, remains a workaround for people who don't care about 'ls -l' workloads). Cheers Trond > -----Original Message----- > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of NeilBrown > Sent: Wednesday, March 16, 2011 12:55 AM > To: Trond Myklebust; Bryan Schumaker > Cc: linux-nfs@vger.kernel.org > Subject: Use of READDIRPLUS on large directories > > > Hi Trond / Bryan et al. > > Now that openSUSE 11.4 is out I have started getting a few reports > of regressions that can be traced to > > commit 0715dc632a271fc0fedf3ef4779fe28ac1e53ef4 > Author: Bryan Schumaker > Date: Fri Sep 24 18:50:01 2010 -0400 > > NFS: remove readdir plus limit > > We will now use readdir plus even on directories that are very large. > > Signed-off-by: Bryan Schumaker > Signed-off-by: Trond Myklebust > > > This particularly affects users with their home directory over > NFS, and with largish maildir mail folders. > > Where it used to take a smallish number of seconds for (e.g.) > xbiff to start up and read through the various directories, it now > takes multiple minutes. > > I can confirm that the slow down is due to readdirplus by mounting the > filesystem with nordirplus. > > > While I can understand that there are sometime benefits in using > readdirplus for very large directories, there are also obviously real > costs. So I think we have to see this patch as a regression that should > be reverted. > > > It would quite possibly make sense to create a tunable (mount option or > sysctl I guess) to set the max size for directories to use readdirplus, > but I think it really should be an opt-in situation. > > [[ It would also be really nice if the change-log for such a significant > change contained a little more justification.... :-( ]] > > Thoughts? > > Thanks, > NeilBrown > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com