On Tue, 15 Dec 2009, Bill Sprouse 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
It seems that Dovecot's speed optimizations for mbox format are
specially designed to break zfs
"http://wiki.dovecot.org/MailboxFormat/mbox#Dovecot.27s_Speed_Optimizations";
and explains why using a tiny 8k recordsize temporarily "improved"
performance. Tiny updates seem to be abnormal for a mail server.
The many tiny updates combined with zfs COW conspire to spread the
data around the disk, requiring a seek for each 8k of data. If more
data was written at once, and much larger blocks were used, then the
filesystem would continue to perform much better, although perhaps
less well initially. If the system has sufficient RAM, or a large
enough L2ARC, then Dovecot's optimizations to diminish reads become
meaningless.
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?
Zfs works best when whole files are re-written rather than updated in
place as Dovecot seems to want to do. Either the user mailboxes
should be re-written entirely when they are "expunged" or else a
different mail storage format which writes entire files, or much
larger records, should be used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
