The cvt_cyrusdb program should do what you need as far as converting the
database.
You want to be sure your version of cyrus supports skiplist though (if it
has cvt_cyrusdb, it does).
So its basically:
Backup.
Rebuild cyrus to have a skiplist mboxlist.
Shutdown Cyrus
Convert database to skiplist
Ok, I´m not using skiplist, since at time of compilation I choose de default
DB3. But now that I have a production environment for at least 15 months using
db3, how can I change it to skiplist, I mean, how could this be done
considering de production environment and users happiness!
Regards
Wa
Sorry, the platform is Compaq/HP AlphaServer 4100 running Cyrus Imap 2.1.5.
Wander
----
Wanderley O. Mendes
Software Specialist [EMAIL PROTECTED]
Phone: +55-12-560-8432 Fax: +55-12-560-8435
INPE/CPTEC - Cachoeira Paulista - São
Jules Agee wrote:
You didn't say what platform you're using... if you are running Cyrus
with the mailstore on a traditional UFS or ext3 filesystem you might
start seeing the filesystem become a bottleneck if a single mailbox has
a lot of messages.
I have found that setting "noatime" in the fil
On Wed, 18 Dec 2002, Jay Levitt wrote:
> Are you using skiplist for your mboxlist? I have over 7000 messages in my
> inbox and it's zippy as can be...
This of course depends on what is being slow. If LIST commands are taking
a long time, using the skiplist backend (as opposed to Berkeley DB) sh
Wander writes:
> Some of our users really doesn´t have much time to decrease the INBOX,
neither
> distributing messages across subfolders or deleting it as fast as could be
> necessary and as consequence, theirs INBOX are growing and growing and
making
> things very slow...
Are you using skiplist
You didn't say what platform you're using... if you are running Cyrus
with the mailstore on a traditional UFS or ext3 filesystem you might
start seeing the filesystem become a bottleneck if a single mailbox has
a lot of messages. We run Cyrus on Linux and also have a lot of users
with very full
Some of our users really doesn´t have much time to decrease the INBOX, neither
distributing messages across subfolders or deleting it as fast as could be
necessary and as consequence, theirs INBOX are growing and growing and making
things very slow... I´m figuring out how many admins could have
