Xref: utzoo comp.arch:22957 comp.protocols.nfs:2376
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!convex!hamrick
From: hamrick@convex.com (Ed Hamrick)
Newsgroups: comp.arch,comp.protocols.nfs
Subject: Re: Large Files (> 2 GByte) w/NFS
Keywords: NFS FFS Filesystem
Message-ID: <1991May28.175809.13532@convex.com>
Date: 28 May 91 17:58:09 GMT
References: <1991May27.170212.18590@convex.com> <10845@chorus.fr>
Sender: usenet@convex.com (news access account)
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Lines: 18
Nntp-Posting-Host: convex1.convex.com

In article <10845@chorus.fr> paulo@soprano.chorus.fr (Paulo Amaral) writes:
>For a 2Gb file, a 512 byte buffer would mean 4M read operations (RPC requests).
>Assuming 2 ms for each RPC it would take more than 2 hours to read a whole file
>whereas with 8kb buffers it would take 8 minutes.

You are quite correct that all NFS reads and writes should be in units of
8 KBytes if possible in order to achieve the best possible performance.
(Another interesting area of discussion is how to increase this to ~64 KBytes
without breaking very much.  HIPPI NFS performance would benefit from this.)

I was referring to the block size reported in the fattr field blocksize.
Things seem to work best when this is set to 512 bytes.  I seem to recall that
this was done to make the "du" utility work properly since it assumes
(in at least one implementation) that the fattr field "blocks" contains the
number of 512 byte blocks allocated to a file.

Regards,
Ed Hamrick