From owner-cvs-all Sat May 30 19:02:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12432 for cvs-all-outgoing; Sat, 30 May 1998 19:02:22 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12271; Sat, 30 May 1998 19:01:42 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id MAA26937; Sun, 31 May 1998 12:01:40 +1000 Date: Sun, 31 May 1998 12:01:40 +1000 From: Bruce Evans Message-Id: <199805310201.MAA26937@godzilla.zeta.org.au> To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: 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 > 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)). 1099511627775 is actually 1TB-1, and 1TB is only the point where the block numbers would turn negative for 512-byte blocks, and 512-byte blocks are only used by msdosfs. On the server, logical block numbers for cache blocks actually turn negative at 2^31 * block_size. The max file size should be 1 smaller than this, or smaller still if the logical block number is not the limit. nfs_serv.c seems to get this right except for the last point. It gives the following max file sizes for ffs: ffs block size nfs current right -------------- --- ------- ----- 4K 8TB-1 4TB-1 4+TB (12 + 1024 + 1024^2 + 1024^3) blocks 8K 16TB-1 8TB-1 16TB-1 16K 32TB-1 16TB-1 32TB-1 32K 64TB-1 32TB-1 64TB-1 64K 128TB-1 64TB-1 128TB-1 The current ffs limits are mostly from doing the same calculation as in nfs_serv.c, except with a bogus block number limit of 2^30 instead of 2^31. This is useful for avoiding overflow bugs near the real limit. The "right" limits are the same as the ones calculated by nfs_serv.c, except for 4K-blocks the strongest constraint is triple indirect block addressing - it gives a limit of approximately block_size*(block_size/4)^3 = 4TB when block_size = 4K. Triple indirect block addressing is buggy in -current and buggier in -stable when block_size > 8K, so much smaller limits might be a good idea, especially when the limits are exported. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message