Xref: utzoo comp.arch:22949 comp.protocols.nfs:2371 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!corton!chorus!soprano.chorus.fr!paulo From: paulo@soprano.chorus.fr (Paulo Amaral) Newsgroups: comp.arch,comp.protocols.nfs Subject: Re: Large Files (> 2 GByte) w/NFS Keywords: NFS FFS Filesystem Message-ID: <10845@chorus.fr> Date: 28 May 91 09:02:59 GMT References: <1991May27.170212.18590@convex.com> Sender: paulo@chorus.fr Reply-To: paulo@soprano.chorus.fr (Paulo Amaral) Organization: Chorus systemes, Saint Quentin en Yvelines, France Lines: 28 In article <1991May27.170212.18590@convex.com>, hamrick@convex.com (Ed Hamrick) writes: %% We recently ported the UniTree file migration package to the CONVEX %% platform, and ran across some NFS issues. UniTree supports files > 2 GBytes %% in length, but NFS is limited to files of 2^31-1 bytes (32 bit int field). %% %% We've modified UniTree to allow access to large files (> 2 GBytes) using NFS %% by always reporting a file length less than 2 GBytes, even when the file is %% larger than this. This allows access to the first 2 GBytes of large files, %% as well as allowing users to use standard file manipulation commands such as %% ls -l, mv, rm, etc. %% ... %% %% I've had the best experiences using NFS block sizes of 512 bytes, as some %% NFS clients assume this (du utility for instance). An NFS client should use %% whatever block size the server reports. %% 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. -- ______ / / /_____/_ ___ Paulo Amaral / /__/ / / / / / Chorus Systemes / / / /__/ /__ /__/ 6 avenue Gustave Eiffel F-78182, St-Quentin-en-Yvelines Cedex Tel: +33 (1) 30 64 82 35 Fax: + 33 (1) 30 57 00 66 E-mail: paulo@chorus.fr OR paulo%chorus.fr@mcsun.EU.net