From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 16:57:38 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2BF516A417 for ; Thu, 30 Aug 2007 16:57:38 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from spacemail2-out.mgmt.space.net (spacemail2-out.mgmt.space.net [194.97.149.148]) by mx1.freebsd.org (Postfix) with ESMTP id 807AA13C45D for ; Thu, 30 Aug 2007 16:57:38 +0000 (UTC) (envelope-from se@FreeBSD.org) X-SpaceNet-SBRS: None X-IronPort-AV: E=Sophos;i="4.19,326,1183327200"; d="scan'208";a="40540128" Received: from mail.atsec.com ([195.30.252.105]) by spacemail2-out.mgmt.space.net with ESMTP; 30 Aug 2007 18:28:13 +0200 Received: from [10.2.2.88] (frueh.atsec.com [217.110.13.170]) (Authenticated sender: se@atsec.com) by mail.atsec.com (Postfix) with ESMTP id 200807209B4; Thu, 30 Aug 2007 18:28:12 +0200 (CEST) Message-ID: <46D6F016.7020005@FreeBSD.org> Date: Thu, 30 Aug 2007 18:28:06 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Juri Mianovich References: <113837.11318.qm@web45609.mail.sp1.yahoo.com> In-Reply-To: <113837.11318.qm@web45609.mail.sp1.yahoo.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, =?ISO-8859-1?Q?=22Dag-Erling_=5C=22Sm=F8rgrav=5C=22=22?= Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 16:57:39 -0000 Juri Mianovich wrote: > tunefs: should optimize for space with minfree < 8% > > but the time optimization setting will stick, as long > as you have at least 6% minfree. This is documented > in the tunefs man page, in fact. > > The answer to my original question "can I force time > optimization if I am below 6%" appears to be "no". > You can successfully set optimization to time, but the > kernel will always (almost immediately) switch it back > to space optimization. Have you ever read the (now ancient) paper about FFS? The file-system needs free space to avoid fragmentation (not the one reported by fsck), which would slow down large file access by several orders of magnitude. So you pay a high price for using up those last few percent of capacity (except in special usage cases). You can easily achieve the effect of always optimizing for time if you create your file system with identical block and fragment sizes. (I'm wondering, whether you know, what optimization for time or space is about???) Optimization for time causes file ends to be stored in full blocks (leaving the rest of the block unused). All, the optimization for space does, is put several files smaller than one block (or file ends) into one block (e.g. if you have got 16KB blocks and 2KB fragments then 2KB + 4KB + 20KB could be put into two 16KB blocks, while optimization for time would require 4 blocks of 16KB to store those same files). In fact, optimization for space allows to fill up all the (previously only partly allocated) blocks for use by small files. And if you start too late to do this, you'll have too many blocks used only to a fraction. Back to the example: If you have only 4 blocks of 16KB, then storing 2KB, 4KB, 20KB will use up those blocks, if you are optimizing for time: F1: Block 1: 2KB (14KB left free) F2: Block 2: 4KB (12KB left free) F3: Block 3: 16KB (full block) Block 4: 4KB (12KB left free) In that case, your disk was full and no more data could be written. If you had switched to optimize for space early (the correct time to switch modes does not so much depend on a percentage of free space, but rather on the ratio of partial blocks to full blocks and to free blocks), this could have all been stored in 2 blocks, leaving half of your space available: F1 + F2 + F3(tail) Block 1: 2KB // 4KB // 4KB (6KB left) F3: Block 2: 16KB (full block) Block 3: (16KB free) Block 4: (16KB free) So if you are willing to waste space for small files (or if you do not expect to store many small files, since the optimization is only used for files that do not require indirect blocks), then create your file system with fragment size equal to block size and waste some space. But I thought you wanted to put as much data on your disk and did not want to waste space? Well, then better let those well thought out optimizations (TM) do their job and do not step in their way ;-) You never mentioned what you are trying to achieve. Their are cases, where a very low min-free man make sense (static file systems consisting of files that are larger than some 200KB). In all other cases you are going to be hurt. All this (and much more) is explained in much detail in the FFS paper by McKusick et.al., see: /usr/share/doc/smm/05.fastfs/paper.ascii.gz Regards, STefan