From: "Paul Smith" <pausmith@nortelnetworks.com>
Subject: Re: NFS client write performance issue ... thoughts?
Date: 06 Jan 2004 01:33:29 -0500
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <vpdrfzetziva.fsf@lemming.engeast.baynetworks.com>
References: <16378.15074.348051.673492@guts.uio.no>
Reply-To: "Paul Smith" <pausmith@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
To: nfs@lists.sourceforge.net
In-Reply-To: <16378.15074.348051.673492@guts.uio.no>
Errors-To: nfs-admin@lists.sourceforge.net

%% Trond Myklebust <trond.myklebust@fys.uio.no> writes:

  tm> P=E5 m=E5 , 05/01/2004 klokka 17:11, skreiv Paul Smith:
  >> Hi all; we've been doing some examination of NFS client performance, a=
nd
  >> have seen this apparently sub-optimal behavior: anyone here have any
  >> comments on this observation or thoughts about it?

  tm> Does your observation include numbers, or is it just conjecture?

Note I'm only forwarding comments I've received from another party,
who's actually doing the investigation.

The application in question is not GDBM but rather ClearCase; I guess
there's some concern that the performance of ClearCase over NFS from a
Linux client seems to be noticeably less than from a Solaris client.
ClearCase uses a (heavily) customized version of the Raima database to
store its internal information.

I'll see if I can get any numbers.

  tm> The Solaris approach is only a win in the particular case where
  tm> you are doing several non-contiguous writes into the same page
  tm> (and without any byte-range locking).  Note that like Linux, two
  tm> processes that do not share the same RPC credentials still cannot
  tm> merge their writes since you cannot rely on them having the same
  tm> file write permissions.

In this particular case that's fine since the ClearCase database is only
ever modified by one process on one system.

  tm> Looking at your particular example of GDBM, you should recall that
  tm> Solaris is forced to revert to uncached synchronous reads and writes
  tm> when doing byte range locking precisely because their page cache
  tm> writes back entire pages (the ugly alternative would be to demand that
  tm> byte range locks must be page-aligned).
  tm> OTOH Linux can continue to do cached asynchronous reads and writes
  tm> right up until the user forces an fsync()+cache invalidation by
  tm> changing the locking range because our page cache writes are not
  tm> required to be page aligned.

Of course I don't have the source and I haven't sniffed the packets
personally so I don't know exactly what goes on, but it's quite possible
that the ClearCase implementation doesn't attempt to do any byte-range
locking at all, since they pretty much know that there is only one
process reading and writing the DB.

The reason for using NFS involves maintenance, backup, reliability,
etc. etc. (the NFS server is actually an EMC or NetApp NAS solution),
not necessarily file sharing, at least insofar as the DB itself is
concerned.


Thanks for the reply, Trond; I'll see if I can get more concrete
details and let you know.

--=20
---------------------------------------------------------------------------=
----
 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & To=
ols
 "Please remain calm...I may be mad, but I am a professional." --Mad Scient=
ist
---------------------------------------------------------------------------=
----
   These are my opinions---Nortel Networks takes no responsibility for them.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs