On 16-Dec-09, at 10:47 AM, Bill Sprouse wrote:
Hi Brent,
I'm not sure why Dovecot was chosen. It was most likely a
recommendation by a fellow University. I agree that it lacking in
efficiencies in a lot of areas. I don't think I would be
successful in suggesting a change at this point as I have already
suggested a couple of alternatives without success.
(As Damon pointed out) The problem seems not Dovecot per se but the
choice of mbox format, which is rather self-evidently inefficient.
Do you a have a pointer to the "block/parity rewrite" tool
mentioned below?
It headlines the informal roadmap presented by Jeff Bonwick.
http://www.snia.org/events/storage-developer2009/presentations/monday/
JeffBonwick_zfs-What_Next-SDC09.pdf
--Toby
bill
On Dec 15, 2009, at 9:38 PM, Brent Jones wrote:
On Tue, Dec 15, 2009 at 5:28 PM, Bill Sprouse
<bill.spro...@sun.com> wrote:
Hi Everyone,
I hope this is the right forum for this question. A customer is
using a
Thumper as an NFS file server to provide the mail store for
multiple email
servers (Dovecot). They find that when a zpool is freshly
created and
populated with mail boxes, even to the extent of 80-90% capacity,
performance is ok for the users, backups and scrubs take a few
hours (4TB of
data). There are around 100 file systems. After running for a
while (couple
of months) the zpool seems to get "fragmented", backups take 72
hours and a
scrub takes about 180 hours. They are running mirrors with about
5TB usable
per pool (500GB disks). Being a mail store, the writes and reads
are small
and random. Record size has been set to 8k (improved performance
dramatically). The backup application is Amanda. Once backups
become too
tedious, the remedy is to replicate the pool and start over.
Things get
fast again for a while.
Is this expected behavior given the application (email - small,
random
writes/reads)? Are there recommendations for system/ZFS/NFS
configurations
to improve this sort of thing? Are there best practices for
structuring
backups to avoid a directory walk?
Thanks,
bill
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Anyone reason in particular they chose to use Dovecot with the old
Mbox format?
Mbox has been proven many times over to be painfully slow when the
files get larger, and in this day and age, I can't imagine anyone
having smaller than a 50MB mailbox. We have about 30,000 e-mail users
on various systems, and it seems the average size these days is
approaching close to a GB. Though Dovecot has done a lot to improve
the performance of Mbox mailboxes, Maildir might be more rounded for
your system.
I wonder if the "soon to be released" block/parity rewrite tool will
"freshen" up a pool thats heavily fragmented, without having to redo
the pools.
--
Brent Jones
br...@servuhome.net
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
