In message <199603062256.RAA23989@pain.lcs.mit.edu>
	so spake "Charles M. Hannum" (mycroft):

> 
>    Actually, I thought about doing this in sys/nfs/nfs_vfsops itself, to
>    make old fstabs that only have rsize specified still work. If it is done
>    there, amd doesn't need to do it anymore I guess.
> 
>    What do you think?
> 
> I think it's bogus.  We should stick with historic practice here.  
> Giving the user an option to change the readdir request size is good,
> but using it where we didn't before is asking for trouble.  There's no
> *need* for this change.

This would seem to violate the rule of least astonishment.  Let's
take the example of someone upgrading to -current (or the next
release for that matter).  If they have rsize specified in fstab
as 1K, NFS performance is going to go to hell with a readdirsize
of 8K (we had this problem with a couple of boxen running BSD/OS).
To the naive user it is going to feel like NetBSD is just slower.
Even if the person figures out it is NFS that is the bottleneck
they are unlikely to find the info they need.  The only thing
that mentions readdirsize is mount_nfs.8 and only then via the
'-I' option.  I can't find any reference to a readdirsize "option"
(for fstab or mount -o) anywhere.

Sure, it's easy to fix up the documentation, but most people
will still expect the readdirsize to be coupled with rsize,
since that's how it has been historically and that's what
other OS's do.  This really isn't a case of using readdirsize
in a new place, it's already there.  It's just a matter of
making readdirsize match rsize iff rsize is set and readdirsize
is not.  This seems better than just defaulting to 8K which
is currently what happens.

 - todd