From owner-freebsd-arch Fri Nov 3 10:27:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id D6A5E37B479 for ; Fri, 3 Nov 2000 10:27:24 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA3IRIM47704; Fri, 3 Nov 2000 10:27:18 -0800 (PST) (envelope-from dillon) Date: Fri, 3 Nov 2000 10:27:18 -0800 (PST) From: Matt Dillon Message-Id: <200011031827.eA3IRIM47704@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group Cc: Dag-Erling Smorgrav , Marius Bendiksen , Randell Jesup , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep References: <200011031440.eA3Eebp39614@cwsys.cwsent.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> Yes. Increasing the number of bytes per inode will reduce the number :> of inodes and thus reduce fsck time. Increasing the number of cylinders :> in a group will localize inodes into bigger chunks, reducing seeking :> and also thus reduce fsck time. : :Wouldn't that tend to generally reduce day-to-day performance as well? :I suspect that Kirk and co. at CSRG had a good reason for choosing the :defaults they did. : :Regards, Phone: (250)387-8437 :Cy Schubert Fax: (250)387-5766 Increasing the bytes per inode simply reduces the number of inodes available on the filesystem -- that is, reduces the number of files you can create. There is no performance penalty but, of course, it makes it more likely that you will run out of inodes. Setting the number of bytes per inode depends heavily on what you intend to use a filesytem for. Increasing the number of cylinders in a cylinder group has the effect of breaking the overall disk into fewer, larger chunks rather then many smaller chunks. It does has no effect on the numebr of inodes. Ask yourself whether it makes sense to break a modern drive up into 2000 chunks, which is what newfs currently does in this example: serv05:/home/dillon# newfs /dev/da1s1d Warning: 116 sector(s) in last cylinder unallocated /dev/da1s1d: 143363980 sectors in 35001 cylinders of 1 tracks, 4096 sectors 70001.9MB in 2188 cyl groups (16 c/g, 32.00MB/g, 4096 i/g) Or whether it makes to break it up into, say, 400 chunks, which is what you get with: serv05:/home/dillon# newfs -c 89 /dev/da1s1d Warning: 116 sector(s) in last cylinder unallocated /dev/da1s1d: 143363980 sectors in 35001 cylinders of 1 tracks, 4096 sectors 70001.9MB in 394 cyl groups (89 c/g, 178.00MB/g, 22400 i/g) super-block backups (for fsck -b #) at: The answer should be self evident. It is true that the bitmaps are larger, but it can also easily be argued that the bitmaps you get with the default are far too small. Modern drives cache data as do filesystems. On a modern system it is not necessary to have the inodes be as close to the data blocks as it once was. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message