From: "Ragnar Kjørstad" <nfs@ragnark.vestdata.no>
To: Matt Heaton <admin@0catch.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: Millions of files and directory caching.
Date: Mon, 21 Oct 2002 14:34:50 +0200 [thread overview]
Message-ID: <20021021143450.E1944@vestdata.no> (raw)
In-Reply-To: <086801c278c7$fd7e19c0$6801a8c0@c1886657a>; from admin@0catch.com on Mon, Oct 21, 2002 at 12:06:26AM -0600
On Mon, Oct 21, 2002 at 12:06:26AM -0600, Matt Heaton wrote:
> 1) Can I increase the cache on the client side to hold the entire=20
> directory structure of both NFS servers?
If your files don't change to often you can extend the NFS cache timers.
See the manpage for mount-options.
> 2) How can I tell if I am just maxing the seek time out on my NFS serve=
r?
iostat?
> 3) Each NFS server serves about 60-100 files per second. Is this too m=
any per second? Could I possibly be maxing
> out seek time on the NFS servers? My IDE Raid card is the 3ware 750 wi=
th 8 individual IDE ports on it.
All the metadata should be cached on the server; how much RAM does your
nfs-servers have?
> 4) Is there anything like cachefs being developed for linux?? Any othe=
r=20
> suggestions for persistent client caching for NFS?
> Free or commercial is fine.
I have only bad experiences with (solaris) cachefs, so I'm not sure
that's it's a goal to develop something exactly like it :)
Anyway; there are lots of alternatives for client-side cache. NFSv4 will
allow better caching - not sure if the current patch-set implements this
though. Inter-mezzo and coda are other attractive alternatives.
Feel free to contact me off the list for more info.
Of course the obvious solution is to have a set of web-proxies in front
of your web-servers, but I guess there is a reason why you're not doing
that...
--=20
Ragnar Kj=F8rstad
Big Storage
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2002-10-21 12:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-21 6:06 Millions of files and directory caching Matt Heaton
2002-10-21 12:34 ` Ragnar Kjørstad [this message]
2002-10-21 17:44 ` Chris Dos
-- strict thread matches above, loose matches on Subject: below --
2002-10-21 14:59 Lever, Charles
[not found] <6440EA1A6AA1D5118C6900902745938E07D54FA9@black.eng.netapp.com>
2002-10-22 21:00 ` Chris Dos
2002-10-23 14:50 pwitting
2002-10-23 18:16 ` Chris Dos
2002-10-23 18:25 ` Benjamin LaHaise
2002-10-23 19:48 ` Philippe Gramoullé
[not found] <Pine.LNX.4.44.0210231159160.17120-100000@guest239.wc.cray.com>
2002-10-23 22:26 ` Chris Dos
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=20021021143450.E1944@vestdata.no \
--to=nfs@ragnark.vestdata.no \
--cc=admin@0catch.com \
--cc=nfs@lists.sourceforge.net \
/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.