Date: Thu, 11 Feb 1999 21:07:25 +0100 (MET) From: "D. Rock" <rock@wurzelausix.CS.Uni-SB.DE> To: bde@zeta.org.au, dillon@apollo.backplane.com Cc: current@FreeBSD.ORG, niels@bakker.net Subject: Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr Message-ID: <199902112007.VAA05841@vodix.aremorika>
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). Ahh, this sounds reasonable. I should have noticed earlier by myself. On my home machine I recently installed another 1GB (actually 997MB) drive. In order to be able to make a release on this disk I created the filesystem with a 4096/512 block size. This saves approx. 50MB for the whole installation. With this block size, my termcap.db is only 765952 Bytes in size. It is interesting that a 4k block size generates a much smaller file than a block size of 512 Bytes... Does this have something to do that 4k is also the page size? NFSv3 doesn't seem to have a st_blksize field. Thus it is set to 512. For v2 it should be the same as for the corresponding local filesystem on the other end. The difference in the \0 Bytes is related by reading the source file: cap_mkdb uses the stdio functions to read in the source file. This again uses fstat() to obtain the optimal block size. Now more comfortable with NFSv3, I will give it another try. I hope my release builds will speed up a little. Daniel 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?199902112007.VAA05841>