Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Feb 2000 09:20:02 -0500 (EST)
From:      Steve Hovey <shovey@buffnet.net>
To:        George Cox <gjvc@gjvc.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: DIRBLKSIZ and NFS_DIRBLKSIZ
Message-ID:  <Pine.BSF.4.05.10002180914400.20457-100000@buffnet11.buffnet.net>
In-Reply-To: <20000218104546.C14651@extremis.demon.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> > Im thinking maybe I could optimize it alittle if I nfs mount with a
> > higher than default DIRBLKSIZ but Im not sure (the -I param) .  Anyone
> > with insight on this?  Or how I might calc a more optimal setting?
> 
> Well, yes you can tweak the NFS block size.  But in the context of this
> message you haven't _really_ explained the symptom.  Are you saying that
> directory lookups are slow over NFS?  What about general reading and
> writing of files?

I suspect the slowness (for awhile I had home dir appearing local
directory hierarchy and it was much faster) to be in directory lookups,
since the use of .forward or procmail files isnt that wide spread, there
isnt much in them when they are utilized, and the inboxes are locally
stored on the mail server in a u/s/userid format.  So the only really
large job the mailer faces in this, is going thru what are admitted large
directories of user home directories.

Is there a way to determine the size of a directory itself?  I ask about
the -I switch as opposed to just a larger NFS blocksize because when I did
a man mount_nfs I saw this switch as a separate param, which to me says it
may relate to a different set of functions and might not relate to the
blocksize that I know would have an effect if I were experiencing just a
slow file read or write.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10002180914400.20457-100000>