From owner-freebsd-hackers Mon Nov 22 22:42:50 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 8A79A14C4F for ; Mon, 22 Nov 1999 22:42:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA02469; Mon, 22 Nov 1999 22:41:29 -0800 (PST) (envelope-from dillon) Date: Mon, 22 Nov 1999 22:41:29 -0800 (PST) From: Matthew Dillon Message-Id: <199911230641.WAA02469@apollo.backplane.com> To: Joe Greco Cc: abial@webgiro.com (Andrzej Bialecki), freebsd-hackers@FreeBSD.ORG Subject: Re: Non-standard FFS parameters References: <199911230601.AAA04318@aurora.sol.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :What's the recommended way to reduce the number of cylinder groups a bit? :-c's maximum limit is affected by combinations of -b and -i, possibly some :others. PHK was talking about new, more sensible values for filesystem :parameters, but I don't know what happened. I just think it's a bit silly :to go generating hundreds of cg's for a 34GB unit... and this _with_ the :max -c setting of 26 (for this fs). : :/dev/vinum/rn8: 63700992 sectors in 15552 cylinders of 1 tracks, 4096 sectors : 31104.0MB in 599 cyl groups (26 c/g, 52.00MB/g, 256 i/g) :super-block backups (for fsck -b #) at: : 32, 106528, 213024, 319520, 426016, 532512, 639008, 745504, 852000, 958496, : :... Joe : :------------------------------------------------------------------------------- :Joe Greco - Systems Administrator jgreco@ns.sol.net Well, -i doesn't effect c/g any where near as much as -b does. Try bumping the block size up to 16K and use '-c 999' and see what newfs tells you the max c/g is. -b 16384 -f 2048 -c 999. On my test it let me do 89 c/g. As we already know, non-standard block sizes will create problems under stable and may create them under current. I believe I have fixed the bugs under current (in getnewbuf()) but since no comprehensive testing has been done you still have a lockup risk. Work on the VM system mainly by Luoqi a few months ago fixed the buffer corruption bugs, so only lockup bugs should be left. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message