From: Paul Dekkers (no email)
Date: Fri Jan 06 2006 - 06:47:49 EST
Hi,
We are about to move our mail to a different machine, running a
different OS and a different filesystem (ext3, since that is "the one"
for RH). While thinking about this filesystem for use with cyrus, I was
wondering if it would do any good to split up the current mailspool in
different imap partitions. I'm curious what others would do. I've
searched the archive a bit, but for now it seems people are only
partitioning for expanding storage...
Currently there are about 7000000 files, split over 14000 mailfolders,
consuming 250 gigabyes, for about 80 users. (Large part of it is a
shared archive, a few have large user boxes.) Everything is on one
partition now.
Does it (filesystem / safety / recovery / performance-wise) make sense
to use different partitions, maybe about 100G large, and spread archive
and users over 3 or 4 partitions, or would you people rather put
everything in a single partition instead? I have about 1 terabyte
available (managed with lvm).
I think about not enabling dir_index on ext3 after discovering that this
dramatically _decreases_ read-performance, so in that perspective this
might keep the filesystem tables more clean and keeps down
fragmentation? But if someone tells me that this really doesn't matter
then I can as well keep everything in one partition: I don't see myself
as a filesystem expert ;-)
Regards,
Paul
P.S. Initially I want to make filesystem-snapshots and rsync the data to
a different mailserver as sort of "hot standby". (Snapshots might be
interesting for partitioning.) Later on we'll be using 2.3 and the
replication code, after we did some more testing with that. But then
we'd drop the redhat package too, and with that the support from redhat
- I assume? Does anyone have experience with the redhat support on
cyrus? (Is it worth running 2.2 for instead of 2.3? ;-))
---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
|
|
|