From owner-freebsd-doc Sun Dec 30 18:27: 5 2001 Delivered-To: freebsd-doc@freebsd.org Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (pop-mu-8-2-dialup-99.freesurf.ch [194.230.141.99]) by hub.freebsd.org (Postfix) with ESMTP id BE15937B417; Sun, 30 Dec 2001 18:26:47 -0800 (PST) Received: from beerswilling.netscum.dyndns.dk (dcf77-zeit.netscum.dyndns.dk [172.27.72.27]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6) with ESMTP id fBV20hi00258 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Mon, 31 Dec 2001 03:00:44 +0100 (CET) (envelope-from bounce@netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/8.11.6) id fBV20hb00257; Mon, 31 Dec 2001 03:00:43 +0100 (CET) (envelope-from bounce@netscum.dyndns.dk) Date: Mon, 31 Dec 2001 03:00:43 +0100 (CET) Message-Id: <200112310200.fBV20hb00257@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery To: freebsd-hackers@freebsd.org, freebsd-doc@freebsd.org Subject: Re: newfs and the -b/-f default values Organization: Men not wearing any pants that dont shave X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: TDC Suisse AG, Rumlang X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [replies sent directly to me may timeout and bounce, since I'm not online as often as I should be, but I'll check the list archives] Not so long ago, I pondered... > So I just now went back into -current and used `newfs -N' with > different parameters, and as far as I could see, in fact, the > new defaults of -b 16384 -f 2048 that the man pages referred to > several times were not in effect. I think I know what's happening. That partition I tried to newfs already had fsize and bsize in the disklabel, and those values were (re)used. Another partition I re-newfs'ed had zero in the disklabel, though they had been earlier newfs'ed with the old defaults, so when I tried to newfs this one, I got the new defaults instead, as promised by the man page. > So, is there a good reason why the -stable and -current man pages > for newfs do not seem to match the reality of what the program does? I think the man pages need to be enhanced to make mention of what happens with non-zero disklabel values. In rereading the man pages in both -stable and -current, I got no obvious hint that this made any difference. I probably should have known better, but... In particular, I'd suggest wording similar to what follows, to make this more clear: -b block-size The block size of the file system, in bytes. It must be a power of 2. The default size is 16384 bytes, and the smallest allow- able size is 4096 bytes. If the disklabel contains a non-zero bsize, that value will be used unless a different value is explicitly specified. The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce unpredictable results. [...] -f frag-size The fragment size of the file system in bytes. It must be a power of two ranging in value between blocksize/8 and blocksize. The default is 2048 bytes. If the disklabel contains a non- zero fsize, that value will be used unless a different value is specified. [...] (From the -current man page for newfs: ) EXAMPLES newfs /dev/ad3s1a Creates a new ufs file system on ad3s1a. If the disklabel values for bsize and fsize are zero, newfs will use a block size of 16384 bytes, a fragment size of 2048 bytes and the largest possible number of cylinders per group. These values tend to produce better performance for most applications than the historical defaults (8192 byte block size and 1024 byte fragment size). This large fragment size may lead to large amounts of wasted space on filesystems that contain a large number of small files. Otherwise, newfs will use the existing disklabel values of bsize and fsize for the block size and fragment size respectively. Assuming that this does reflect reality. I'm sure someone with a much better grip on the english language than I can state it far more succinctly, just as someone with a much better grip on newfs than I could far more accurately describe reality. thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message