linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: peter.staubach@emc.com
Cc: neilb@suse.de, bjschuma@netapp.com, linux-nfs@vger.kernel.org
Subject: RE: Use of READDIRPLUS on large directories
Date: Wed, 16 Mar 2011 09:50:04 -0400	[thread overview]
Message-ID: <1300283404.16266.41.camel@lade.trondhjem.org> (raw)
In-Reply-To: <5E6794FC7B8FCA41A704019BE3C70E8B068397B4@MX31A.corp.emc.com>

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 <bjschuma@netapp.com>
> 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 <bjschuma@netapp.com>
>     Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> 
> 
> 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


  reply	other threads:[~2011-03-16 13:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-16  4:55 Use of READDIRPLUS on large directories NeilBrown
2011-03-16 12:30 ` peter.staubach
2011-03-16 13:50   ` Trond Myklebust [this message]
2011-03-16 21:40   ` NeilBrown
2011-03-17  0:55     ` NeilBrown
2011-03-17 17:44       ` J. Bruce Fields
2011-03-18  4:27         ` NeilBrown
2011-03-16 13:43 ` Chuck Lever
2011-03-16 14:14   ` Bryan Schumaker
2011-03-16 14:20     ` Trond Myklebust
2011-03-16 21:30       ` NeilBrown
2011-03-16 21:42         ` Trond Myklebust
2011-03-16 22:40           ` NeilBrown
2011-03-17 17:18             ` J. Bruce Fields
2011-04-04 20:14               ` Bryan Schumaker
2011-04-05 12:20                 ` NeilBrown
2011-04-07 14:28                   ` Bryan Schumaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1300283404.16266.41.camel@lade.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=bjschuma@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=peter.staubach@emc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).