From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Peter Staubach <staubach@redhat.com>
Cc: Olaf Kirch <okir@suse.de>, Greg Banks <gnb@melbourne.sgi.com>,
Linux NFS Mailing List <nfs@lists.sourceforge.net>,
Chuck Lever <chucklever@gmail.com>
Subject: Re: [PATCH 3/4] Add /proc/sys/fs/nfs sysctls to nfsd module
Date: Mon, 07 Aug 2006 00:02:17 -0400 [thread overview]
Message-ID: <1154923337.5677.42.camel@localhost> (raw)
In-Reply-To: <44D39D18.7080907@redhat.com>
On Fri, 2006-08-04 at 15:16 -0400, Peter Staubach wrote:
> > Sucks, sucks, sucks....
>
> Actually, the Solaris implementation matches the intended semantics as
> described in RFC1813. The number of bytes of requested information
> via readdir(3) is passed via dircount and then the maximum size of the
> response is passed through maxcount.
>
> The two fields were intended to be used to reduce the overhead on
> the server by passing a hint for the amount of data that the client
> was actually looking for and then a count for the maximum sized response
> that it was prepared to handle.
Right. At first glance a good idea, but in practice it sucks because the
client has no idea of how much data it was looking for. In order to
know, it would need to know the length of the filenames in the
directory. Unless it is already caching the directory, that will be 100%
guesswork.
Cheers,
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2006-08-07 4:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-03 11:05 [PATCH 3/4] Add /proc/sys/fs/nfs sysctls to nfsd module Olaf Kirch
2006-08-03 16:52 ` Chuck Lever
2006-08-03 17:08 ` Trond Myklebust
2006-08-04 17:55 ` Olaf Kirch
2006-08-04 8:43 ` Greg Banks
2006-08-04 15:36 ` Trond Myklebust
2006-08-04 17:52 ` Olaf Kirch
2006-08-04 18:23 ` Trond Myklebust
2006-08-04 19:16 ` Peter Staubach
2006-08-04 20:06 ` Olaf Kirch
2006-08-07 4:02 ` Trond Myklebust [this message]
2006-08-04 23:36 ` Neil Brown
2006-08-05 13:15 ` Olaf Kirch
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=1154923337.5677.42.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=chucklever@gmail.com \
--cc=gnb@melbourne.sgi.com \
--cc=nfs@lists.sourceforge.net \
--cc=okir@suse.de \
--cc=staubach@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.