[Dovecot] mail spool filesystem

Felipe Scarel fbscarel at gmail.com
Fri Aug 19 22:07:56 EEST 2011


Thanks, I've read some of the FAQ and install instructions and it seems
pretty straightforward... I wish I could use Solaris but we're virtualizing
everything on our Dell blade through VMWare ESXi and it's somewhat of a
"company policy" to use the template Debian that's maintained by the senior
sysadmin.

About the compression, I've read some benchmarks/tests and the default lzjb
algorithm seems to be a good cost/benefit for the usual applications.
Without many reads to the filesystem, gzip compresses a whole lot better
tho.

On Fri, Aug 19, 2011 at 16:01, Dave McGuire <mcguire at neurotica.com> wrote:

>
>  Good luck!
>
>  FYI, my mail spools are on ZFS filesystems under Solaris on UltraSPARC.
>  It is lightning fast with 100+ dovecot imap processes pounding away.  I've
> not yet enabled compression and done the copy/recopy dance, though.
>
>           -Dave
>
>
> On 08/19/2011 02:57 PM, Felipe Scarel wrote:
>
>> I was not aware of that... I went with FUSE to test the deduplication
>> feature of ZFS. I'll check out this link you've provided, many thanks
>> Dave.
>> :)
>>
>> On Fri, Aug 19, 2011 at 15:48, Dave McGuire<mcguire at neurotica.com>
>>  wrote:
>>
>>  On 08/19/2011 02:45 PM, Felipe Scarel wrote:
>>>
>>>  I'm testing out ZFS-fuse on my new install (talked about it on the other
>>>> thread), no issues so far. The builtin deduplication and compression
>>>> sure
>>>> do
>>>> help a lot, roughly 30% less storage space required so far.
>>>>
>>>> They don't advertise it as exactly "production" quality, but I'm willing
>>>> to
>>>> try it out, we're doing regular backups. The mail system hasn't gone
>>>> live
>>>> yet though, so I'm a bit uneasy on the performance side of things under
>>>> heavy load.
>>>>
>>>>
>>>  You are aware that there's a real in-kernel ZFS implementation under
>>> Linux
>>> now, right?  See http://zfsonlinux.org/.  I've done some very basic
>>> testing with it, and so far, it works.  Going through FUSE is slower than
>>> pissing tar; this implementation won't have that problem.
>>>
>>>  FUSE is useful for many things.  Performance-sensitive filesystems on
>>> production servers is oh-so-NOT one of them. ;)
>>>
>>>             -Dave
>>>
>>> --
>>> Dave McGuire
>>> Port Charlotte, FL
>>>
>>>
>>
>
> --
> Dave McGuire
> Port Charlotte, FL
>


More information about the dovecot mailing list