From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 29 22:40:33 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 EC6B116A421 for ; Thu, 29 Sep 2005 22:40:33 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C2A243D76 for ; Thu, 29 Sep 2005 22:40:25 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 59081 invoked by uid 399); 29 Sep 2005 22:40:22 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 29 Sep 2005 22:40:22 -0000 Received: (qmail 34807 invoked by uid 399); 29 Sep 2005 22:40:22 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 29 Sep 2005 22:40:22 -0000 Message-ID: <433C6D51.8020409@FreeBSD.org> Date: Thu, 29 Sep 2005 15:40:17 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Meyer References: <433B3F41.8060004@spintech.ro> <17211.19772.562587.908715@bhuda.mired.org> <433C5C8B.6000003@FreeBSD.org> <17212.24219.445685.297552@bhuda.mired.org> In-Reply-To: <17212.24219.445685.297552@bhuda.mired.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, aanton@smtpx.spintech.ro 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: Thu, 29 Sep 2005 22:40:35 -0000 Mike Meyer wrote: > This seems very reasonable. The trick is figuring out what "the median > file size" is. I grabbed my mail archive, but that's unlikely to be > representative of most users. You either need to guess right, or make > arrangements to reformat the file system using current dasa at regular > intervals. Sorry if I wasn't explicit enough. I was suggesting that the user who submitted the original message actually measure this, and then yes, a newfs'ing of the file system will be necessary. Or you could of course create a new data disk, formatted to fit your specs, then copy the data over, etc. > Taking Doug's suggestion into account, and using the data I had, the > correct answer would be an 8K/1K file system, possibly with "-i 2048" to > double the number of inodes. I'm not convinced that increasing the number of inodes in this way would be the right way to go. The default is 4*, which is usually pretty reasonable. I imagine (although it's impossible to state conclusively without seeing the files), that the inode problem is a symptom, and that tuning the block size will fix the real problem. > However, I did see an interesting possibility. What do you do if the > median file size is, for example, 4.1K? You make the block size 8k. > 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. hth, Doug -- This .signature sanitized for your protection