Date: Sun, 31 May 1998 12:01:40 +1000 From: Bruce Evans <bde@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 Message-ID: <199805310201.MAA26937@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805310201.MAA26937>