From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Re: NFS client write performance issue ... thoughts? Date: Fri, 9 Jan 2004 22:30:24 +0100 (CET) Sender: nfs-admin@lists.sourceforge.net Message-ID: <32997.141.211.133.197.1073683824.squirrel@webmail.uio.no> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_20040109223024_89784" Cc: Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.24) id 1Af4DB-0007mz-3Z for nfs@lists.sourceforge.net; Fri, 09 Jan 2004 13:30:33 -0800 Received: from pat.uio.no ([129.240.130.16] ident=7411) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.30) id 1Af4DA-0000ZL-Do for nfs@lists.sourceforge.net; Fri, 09 Jan 2004 13:30:32 -0800 To: Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: ------=_20040109223024_89784 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit P� to , 08/01/2004 klokka 12:47, skreiv Paul Smith: > Do you know when those accounting errors were fixed? In the official kernels? 2.4.22, I believe... However there are patches going back to 2.4.19... See http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.19/ The main patch you want will be linux-2.4.19-14-call_start.dif > > ClearCase implements its own virtual filesystem type, and so is > heavily tied to specific kernels (the kernel module is not open source > of course :( ). We basically can move to any kernel that has been > released as part of an official Red Hat release (say, 2.4.20-8 from > RH9 would work), but no other kernels can be used (the ClearCase > kernel module has checks on the sizes of various kernel structures and > won't load if they're not what it thinks they should be--and since > it's a filesystem it cares deeply about structures that have tended to > change a lot. It won't even work with vanilla kernel.org kernels of > the same version.) Blech... Note: if you want to try implementing a scheme like what you propose, then the simplest way to do it, would be to add something like the following patch. It disables nfs_strategy(), then causes nfs_updatepage() to extend the request size if it sees that we're not using byte-range locking, and the complete page is in cache. Cheers, Trond ------=_20040109223024_89784 Content-Type: text/html; name="untitled-1.2" Content-Disposition: attachment; filename="untitled-1.2"