From owner-freebsd-arch Mon Dec 10 1:33:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 985B737B416 for ; Mon, 10 Dec 2001 01:33:40 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16DMqE-000DtB-00; Mon, 10 Dec 2001 11:35:18 +0200 From: Sheldon Hearn To: Kirk McKusick Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Fri, 07 Dec 2001 11:12:57 PST." <200112071913.fB7JCvf29494@beastie.mckusick.com> Date: Mon, 10 Dec 2001 11:35:18 +0200 Message-ID: <53392.1007976918@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 07 Dec 2001 11:12:57 PST, Kirk McKusick wrote: > FYA, we had this same debate a bit over a decade ago when we changed > the default from 4K/512 to 8K/1K. Obviously, we decided not to > special case small filesystems then despite great hand-wringing over > what would happen... Thanks. This takes a load off my shoulders with respect to our tendency to repeat our mistakes in ignorance of our history. :-) Here's what I intend to commit. Ciao, Sheldon. Index: share/man/man7/tuning.7 =================================================================== RCS file: /home/ncvs/src/share/man/man7/tuning.7,v retrieving revision 1.29 diff -u -d -r1.29 tuning.7 --- share/man/man7/tuning.7 7 Dec 2001 18:17:37 -0000 1.29 +++ share/man/man7/tuning.7 10 Dec 2001 09:23:48 -0000 @@ -199,19 +199,29 @@ .Pp .Fx performs best when using 8K or 16K filesystem block sizes. -The default filesystem block size is 8K. -For larger partitions it is usually a good -idea to use a 16K block size. -This also requires you to specify a larger +The default filesystem block size is 16K, +which provides best performance for most applications, +with the exception of those that perform random access on large files +(such as database server software). +Such applications tend to perform better with a smaller block size, +although modern disk characteristics are such that the performance +gain from using a smaller block size may not be worth consideration. +Using a block size larger than 16K +can cause fragmentation of the buffer cache and +lead to lower performance. +.Pp +The defaults may be unsuitable +for a filesystem that requires a very large number of inodes +or is intended to hold a large number of very small files. +Such a filesystem should be created with an 8K or 4K block size. +This also requires you to specify a smaller fragment size. We recommend always using a fragment size that is 1/8 the block size (less testing has been done on other fragment size factors). The .Xr newfs 8 options for this would be -.Dq Li "newfs -f 2048 -b 16384 ..." . -Using a larger block size can cause fragmentation of the buffer cache and -lead to lower performance. +.Dq Li "newfs -f 1024 -b 8192 ..." . .Pp If a large partition is intended to be used to hold fewer, larger files, such as a database files, you can increase the Index: sbin/newfs/newfs.8 =================================================================== RCS file: /home/ncvs/src/sbin/newfs/newfs.8,v retrieving revision 1.47 diff -u -d -r1.47 newfs.8 --- sbin/newfs/newfs.8 7 Dec 2001 13:18:28 -0000 1.47 +++ sbin/newfs/newfs.8 10 Dec 2001 09:11:49 -0000 @@ -110,7 +110,7 @@ for more details on how to set this option. .It Fl b Ar block-size The block size of the file system, in bytes. It must be a power of 2. The -default size is 8192 bytes, and the smallest allowable size is 4096 bytes. +default size is 16384 bytes, and the smallest allowable size is 4096 bytes. The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce unpredictable results. @@ -141,7 +141,7 @@ .Ar blocksize Ns /8 and .Ar blocksize . -The default is 1024 bytes. +The default is 2048 bytes. .It Fl g Ar avgfilesize The expected average file size for the file system. .It Fl h Ar avgfpdir @@ -271,15 +271,19 @@ bad sector allocation. .El .Sh EXAMPLES -.Dl newfs -b 16384 -f 2048 /dev/ad3s1a +.Dl newfs /dev/ad3s1a .Pp Creates a new ufs file system on .Pa ad3s1a . .Nm 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 than the defaults -for most applications. +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. .Sh SEE ALSO .Xr fdformat 1 , .Xr disktab 5 , Index: sbin/newfs/newfs.c =================================================================== RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v retrieving revision 1.45 diff -u -d -r1.45 newfs.c --- sbin/newfs/newfs.c 3 Nov 2001 08:35:11 -0000 1.45 +++ sbin/newfs/newfs.c 7 Dec 2001 15:09:18 -0000 @@ -98,8 +98,8 @@ * sectorsize <= DESFRAGSIZE <= DESBLKSIZE * DESBLKSIZE / DESFRAGSIZE <= 8 */ -#define DFL_FRAGSIZE 1024 -#define DFL_BLKSIZE 8192 +#define DFL_FRAGSIZE 2048 +#define DFL_BLKSIZE 16384 /* * Cylinder groups may have up to many cylinders. The actual Index: usr.sbin/sysinstall/install.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/sysinstall/install.c,v retrieving revision 1.312 diff -u -d -r1.312 install.c --- usr.sbin/sysinstall/install.c 9 Dec 2001 09:47:09 -0000 1.312 +++ usr.sbin/sysinstall/install.c 10 Dec 2001 00:20:21 -0000 @@ -1121,7 +1121,7 @@ variable_set2(SYSTEM_STATE, "update", 0); else variable_set2(SYSTEM_STATE, "init", 0); - variable_set2(VAR_NEWFS_ARGS, "-b 8192 -f 1024", 0); + variable_set2(VAR_NEWFS_ARGS, "", 0); variable_set2(VAR_CONSTERM, "NO", 0); return DITEM_SUCCESS; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message