From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 02:17:56 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DA2416A41F; Fri, 30 Sep 2005 02:17:56 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A7C943D48; Fri, 30 Sep 2005 02:17:55 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j8U2HioU009196; Thu, 29 Sep 2005 19:17:48 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509300217.j8U2HioU009196@gw.catspoiler.org> Date: Thu, 29 Sep 2005 19:17:44 -0700 (PDT) From: Don Lewis To: dougb@FreeBSD.org In-Reply-To: <433C6D51.8020409@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, aanton@smtpx.spintech.ro, mwm@mired.org Subject: Re: journaling fs and large mailbox format 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: Fri, 30 Sep 2005 02:17:56 -0000 On 29 Sep, Doug Barton wrote: > Mike Meyer wrote: >> A 4K block won't hold your median file. But an 8K block wastes a lot of >> space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 >> will do that, which doesn't seem good. If UFS2 won't do that, you get a >> lot of half-empty blocks, which likewise isn't good. The other option is >> a 4K block size, which means you get a lot of 1 block + 1 frag files. >> That seems optimal in this case. > > That's a logical analysis, but you're missing one important premise. UFS > doesn't do "more than one file per frag" until the file system gets close to > filling up, and the optimization switches from time to space. Therefore, in > your example you're actually wasting more space than you would with 8k > blocks, and as a side effect making the fs less efficient in at least 2 ways. If you know that most of the files are write-once and don't grow over time, you can tune the file system to always do space optimization. I used to do this with classic Usenet spools and it worked well.