From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 13 03:40:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B521F106564A for ; Sun, 13 Feb 2011 03:40:06 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by mx1.freebsd.org (Postfix) with ESMTP id 6E33B8FC0A for ; Sun, 13 Feb 2011 03:40:06 +0000 (UTC) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id p1D3e5C3024902 for ; Sat, 12 Feb 2011 22:40:05 -0500 Received: from dieterbsd@engineer.com by imo-da03.mx.aol.com (mail_out_v42.9.) id n.ff6.586c06e (55742) for ; Sat, 12 Feb 2011 22:40:00 -0500 (EST) Received: from smtprly-me02.mx.aol.com (smtprly-me02.mx.aol.com [64.12.95.103]) by cia-md05.mx.aol.com (v129.7) with ESMTP id MAILCIAMD051-b2cd4d57528e32; Sat, 12 Feb 2011 22:40:00 -0500 Received: from web-mmc-d04 (web-mmc-d04.sim.aol.com [205.188.103.94]) by smtprly-me02.mx.aol.com (v129.8) with ESMTP id MAILSMTPRLYME025-b2cd4d57528e32; Sat, 12 Feb 2011 22:39:58 -0500 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Feb 2011 22:39:58 -0500 X-MB-Message-Source: WebUI X-AOL-IP: 67.206.170.129 X-MB-Message-Type: User MIME-Version: 1.0 From: dieterbsd@engineer.com Content-Type: text/plain; charset="us-ascii" X-Mailer: Mail.com Webmail 33222-STANDARD Received: from 67.206.170.129 by web-mmc-d04.sysops.aol.com (205.188.103.94) with HTTP (WebMailUI); Sat, 12 Feb 2011 22:39:58 -0500 Message-Id: <8CD9946D22CB89E-1B70-1C204@web-mmc-d04.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Subject: Re: memstick.img is bloated with 7% 2K blocks of nulls X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 03:40:06 -0000 Tim Kientzle wrote: > The current UFS code is designed to leave enough "slack space" to > support future file writes. What if you turned the knob all the way down and had just one cylinder group? I assume that newfs would need to be fixed to allow this, but would anything break? The current limits are also wasteful for normal read/write filesystems with large files. Too many cylinder groups, too many inodes, block/frag size too small, etc...