From owner-cvs-all Sat May 30 09:34:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA28298 for cvs-all-outgoing; Sat, 30 May 1998 09:34:12 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA28292; Sat, 30 May 1998 09:34:09 -0700 (PDT) (envelope-from peter@FreeBSD.org) From: Peter Wemm Received: (from peter@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id JAA05628; Sat, 30 May 1998 09:33:59 -0700 (PDT) Date: Sat, 30 May 1998 09:33:59 -0700 (PDT) Message-Id: <199805301633.JAA05628@freefall.freebsd.org> To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: cvs commit: src/sys/nfs nfs_bio.c nfs_serv.c nfs_vfsops.c nfs_vnops.c nfsmount.h Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk peter 1998/05/30 09:33:59 PDT Modified files: sys/nfs nfs_bio.c nfs_serv.c nfs_vfsops.c nfs_vnops.c nfsmount.h Log: When using NFSv3, use the remote server's idea of the maximum file size rather than assuming 2^64. It may not like files that big. :-) On the nfs server, calculate and report the max file size as the point that the block numbers in the cache would turn negative. (ie: 1099511627775 bytes (1TB)). One of the things I'm worried about however, is that directory offsets are really cookies on a NFSv3 server and can be rather large, especially when/if the server generates the opaque directory cookies by using a local filesystem offset in what comes out as the upper 32 bits of the 64 bit cookie. (a server is free to do this, it could save byte swapping depending on the native 64 bit byte order) Obtained from: NetBSD Revision Changes Path 1.57 +7 -2 src/sys/nfs/nfs_bio.c 1.62 +12 -6 src/sys/nfs/nfs_serv.c 1.64 +14 -1 src/sys/nfs/nfs_vfsops.c 1.90 +3 -3 src/sys/nfs/nfs_vnops.c 1.15 +2 -1 src/sys/nfs/nfsmount.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message