Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Sep 2005 14:28:43 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        Mike Meyer <mwm@mired.org>
Cc:        freebsd-hackers@freebsd.org, aanton@smtpx.spintech.ro
Subject:   Re: journaling fs and large mailbox format
Message-ID:  <433C5C8B.6000003@FreeBSD.org>
In-Reply-To: <17211.19772.562587.908715@bhuda.mired.org>
References:  <433B3F41.8060004@spintech.ro> <17211.19772.562587.908715@bhuda.mired.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Meyer wrote:

> The solution isn't to avoid Maildir/mh - the solution is to tune the
> file system for the expected usage. FreeBSD (and Unix in general)
> gives you lots of knobs to deal with things like this. Learn to use
> them.
> 
> The default block and frag size are relatively large - 2K and 16K
> appear to be the defaults on 5.x. A quick look at my mail for 2005
> shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean
> size of less than 8K. I'd go with 4k blocks and a 512 byte frag size -
> because that will give you four times as many inodes as the default
> parameters. 8K/1K is also tempting, but you'll probably want to
> specify -i 2048 to get the same number of inodes as you get with a
> 4K/512b file system.

I agree generally with your thinking here, and wanted to add a little more 
analysis based on my experience. When I was facing a similar problem with a 
large authoritative name server installation, I got the advice to find the 
median file size, and tune the file system so that the block size was 2x the 
median file size (with the fragment size being 1/8th the block size of 
course). The reasoning behind this was that because the files I was working 
with could grow, it made sense to make sure that even if it grew the file 
could stay within one block. This is slightly wasteful of space (very 
slightly), but resulted in a much more efficient operation.

In this situation, since any given file in a maildir directory is very 
unlikely to grow, it seems to me to make sense that the right way to tune 
the fs would be to find the median file size and make the block size large 
enough to handle files of that size. That should give you the right tradeoff 
between speed and efficiency.

hth,

Doug

-- 

     This .signature sanitized for your protection




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?433C5C8B.6000003>