From owner-freebsd-hackers Tue Oct 5 21:49:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CB03B156AE for ; Tue, 5 Oct 1999 21:49:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA81656; Tue, 5 Oct 1999 21:49:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 5 Oct 1999 21:49:09 -0700 (PDT) From: Matthew Dillon Message-Id: <199910060449.VAA81656@apollo.backplane.com> To: Andrzej Bialecki Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Non-standard FFS parameters References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, : :The system in question (3.3-stable) needs to use a large FS (ca. 40GB). :The defaults for such filesystem are ridiculous, given that it will hold :at most couple of hundred big data files. So, my question is: : :* should I change the cpg (default 16) to some bigger value? No, let newfs figure it out. :* is it safe to run production system with non-standard block and fragment :size (e.g. 32768 and 4096)? Mmmm. I ran into problems in -current trying to use a block size of 64K. It should be relatively easy for me to track this down and fix it, but I don't know if there are other problems lying in wait. test3:/root# ps axl | fgrep nbuf 0 14265 14201 0 -2 0 620 536 nbufkv D+ p0 0:02.55 cpdup / /mnt :* what maximum value can I use for -i (bytes per inode) parmeter? I :aalready tried 16mln ... I wouldn't go that high. Try 262144. Here's an example: newfs -i 262144 -b 65536 -f 8192 /dev/rvn1c test3:/root# newfs -i 262144 -f 8192 -b 65536 /dev/rvn1c /dev/rvn1c: 83886080 sectors in 2560 cylinders of 1 tracks, 32768 sectors 40960.0MB in 160 cyl groups (16 c/g, 256.00MB/g, 1024 i/g) :* and finally, how th above choices affect the FS performance in my case? : :Thanks in advance for any insights! : :Andrzej Bialecki The higher the bytes per inode the fewer the inodes and the faster fsck will run if you have to recover the filesystem. Too high a bytes-per-inode will screw up the filesystem's ability to manage the cylinder groups, though. The higher the block size the fewer indirect blocks are required to access a linear file, but as the block size increases the system's caching effectiveness will decrease. I would not use a block size greater then 64K, and I wouldn't specify a bytes-per-inode greater then 262144. There may be problems specifying larger block sizes, though nothing that we can't fix. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message