Date: Fri, 12 Feb 1999 02:47:38 +1100 From: Bruce Evans <bde@zeta.org.au> To: dillon@apollo.backplane.com, rock@cs.uni-sb.de Cc: current@FreeBSD.ORG, niels@bakker.net, rock@wurzelausix.CS.Uni-SB.DE Subject: Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr Message-ID: <199902111547.CAA16712@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>As I writed some time before, I always get the wrong results if I generate >the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine >is the NFS server (tried Solaris 7 and the NFS client machine itself). The >generated file has *always* the wrong size (always the same: 1077760 Bytes, >instead of 1245184 Bytes, which it should have). With NFSv2 the output is >OK. 1077760 seems to be correct. The different sizes are caused by the db library believing that statbuf.st_blksize actually gives the optimal blocksize for I/O. For nfsv3, st_blksize is 512, and this gives a smaller database, but for nfsv2 st_blksize seems to be determined by the server. I get the following results after hacking the db library to use a fixed blocksize: blocksize 8192: ufs db file size = nfs db file size = 1245184, and files same blocksize 512: ufs db file size = nfs db file size = 1077760, but files differ The differences seem to be mostly for randomly sized bunches of \0's appearing at different places in the files. cap_mkdb is incredibly slow (140 seconds on a P5/133 for an nfs output file). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902111547.CAA16712>