From owner-freebsd-performance@FreeBSD.ORG Mon Dec 12 23:50:36 2011 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73169106566B for ; Mon, 12 Dec 2011 23:50:36 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 1BBB88FC08 for ; Mon, 12 Dec 2011 23:50:36 +0000 (UTC) Received: (qmail 26511 invoked by uid 0); 12 Dec 2011 23:50:35 -0000 Received: from 67.206.184.126 by rms-us005.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 12 Dec 2011 18:50:33 -0500 From: "Dieter BSD" Message-ID: <20111212235034.218250@gmx.com> MIME-Version: 1.0 To: freebsd-performance@freebsd.org,freebsd-fs@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: HfaUbiU03zOlNR3dAHAhLPF+IGRvbwBx Cc: Subject: Maximum blocksize for FFS? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 23:50:36 -0000 Many recent disks have a 4KiB sector size, so newfs's default 2KiB frag size seems suboptimal for these drives. Newfs's man page states: "The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce poor results."  (It is not clear to me what the 8:1 ratio optimizes, or exactly what poor results one should expect with a different ratio?) Thus one would logically think of using 32 KiB blocksize 4KiB fragsize at a minimum with these drives. But, from a discussion in 2009: Bruce Evans wrote: > Any block size above the default (16K) tends to thrash and fragment buffer > cache virtual memory.  This is obviously a good pessimization with lots of > small files, and apparently, as you have found, it is a good pessimization > with a few large files too.  I think severe fragmentation can easily take > several seconds to recover from.  The worst case for causing fragmentaion > is probably a mixture of small and large files. This caused a *severe* performance problem and I was forced to reduce to reduce my blocksize to 16KiB.  :-( For data filesystems with large files (multi GB), there are many advantages to using large blocksizes such as less space wasted on bookkeeping, and faster fsck times. So I'm wondering if this buffer cache virtual memory thrashing/fragmenting problem has been fixed?  Is it safe to use 64KiB/8KiB yet?  IIRC I've read concerns about thrashing/fragmenting due to different filesystems having different sizes, say one filesystem being 16K/2K and another being 64k/8K? Also, has the "bug in vfs_bio.c" been fixed? (64KiB blocksize can hang the system) Any other gottchas?