SUMMARY: Re: General NFS question

From: Adam and Christine Levin (
Date: Tue May 23 2000 - 07:19:33 CDT

On Mon, 22 May 2000, Adam and Christine Levin wrote:
> We've got a production setup here, and I've been debating whether to use
> NFS or not.
> My worries are performance and stability based.
> First off, all systems are Sun E250/E450 level systems running Solaris
> 2.6.
> Mostly, this has to do with logs. The applications we run are
> client-server based, and the server wants the client logs for some
> processes it runs. The clients log locally.
> We could
> 1) mount the logging area from the server to the clients and have the
> clients write over the mount, which I take as a Bad Idea(tm).
> 2) mount the logging area from the client to the server read-only.
> 3) Find another way, like rsyncing the log files every X minutes.
> In the case of 2, I'm worried if we happen to take one of the clients down
> that the server will funk out. I'm also worried that the server will chew
> up a lot of client processor when it starts crunching on those log files
> (since NFS is a kernel thread). The log files are on the order of tens of
> MB per day, and will approach 100MB per day.
> Any thoughts on why NFS would be a bad idea, or why I shouldn't be afraid
> to use it in production?

Thanks to:
David Evans <>
Hendrik Visage <>
Craig Russell <>
Gerhard den Hollander <>
vogelke <>

1) Performance probably wouldn't be an issue, because even 100MB/day isn't
a whole lot for a 100Mbit network.
2) Don't shore from both clients and mount on the server, because then the
server is dependant on *two* mounts.
3) The write hit wouldn't be too bad, and that was suggested a couple of
times (share from the server and mount on the clients).
4) Be careful if the clients need to lock files
5) rsync is probably a good alternative.

I think in order to avoid any possible problems with NFS performance and
stability, I'm going to use rsync. We already use it someplace else over
a WAN connection where NFS wouldn't do, so I'm going to use the same
scheme to avoid any potential problems.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:08 CDT