incremental squatter

[Paolo Cravero]

Hi.
Perhaps it is a bug in the documentation.

'man squatter' in the DESCRIPTION says there's no incremental update:

"Squatter creates an index of ALL messages in the mailbox, not just those 
since the last time that it was run (i.e.,  it  does  NOT  do  incremental 
updates)."

but in the OPTIONS a "-i" switch mentions incremental.

Is it just a documentation error, so incremental indexing does work in 2.3.14?

TIA,
Paolo



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Logging region out of memory

[Marc Patermann]

Hi,

I have IMAPd 2.2.12 and BDB 4.2.52:

When I got:

Sep  2 11:28:39 rzhs199 local6:warn|warning lmtpunix[1171642]: DBERROR
db4: Logging region out of memory; you may need to increase its size
Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[1171642]: DBERROR:
opening /mail/imap/ptclient/ptscache.db: Not enough space
Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[1171642]: DBERROR:
opening /mail/imap/ptclient/ptscache.db: cyrusdb error

Sep  2 11:28:39 rzhs199 local6:warn|warning lmtpunix[4227234]: DBERROR
db4: Logging region out of memory; you may need to increase its size
Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[4227234]: DBERROR:
opening /mail/imap/deliver.db: Not enough space
Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[4227234]: DBERROR:
opening /mail/imap/deliver.db: cyrusdb error
Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[4227234]: FATAL:
lmtpd: unable to init duplicate delivery database

Mass mail could not be delivered in time because LMTP had errors.

I found DB_CONFIG in /mail/imap/

:/mail/imap # cat DB_CONFIG
set_cachesize 0 8388608 8
set_lg_regionmax 524288
set_lg_bsize 2097152

and these files

:/mail/imap # l
45888 insgesamt
drwxr-xr-x  12 cyruscyrus  4096 02 Sep 12:00 .
drwxr-xr-x   6 cyruscyrus   256 28 Jun 2007  ..
-rw---   1 cyruscyrus   144 02 Sep 12:03 annotations.db
drwxrws---   2 cyruscyrus  4096 02 Sep 04:14 db
drwx--   2 cyruscyrus   256 02 Sep 11:44 db.backup1
drwx--   2 cyruscyrus   256 02 Sep 11:14 db.backup2
-rw-r--r--   1 cyruscyrus72 08 Jan 2009  DB_CONFIG
-rw---   1 cyruscyrus  21336064 02 Sep 12:03 deliver.db
drwxr-xr-x   2 root system  256 29 Nov 2007  lost+found
-rw---   1 cyruscyrus   1106000 02 Sep 12:03 mailboxes.db
-rw-rw   1 cyruscyrus689810 02 Sep 11:37 mailboxes.tsm
-rw-r-   1 root system8 20 Apr 10:45 master.pid
drwxrws---   2 cyruscyrus   256 29 Nov 2007  msg
drwxrws---   2 cyruscyrus102400 02 Sep 12:04 proc
drwxrws---   2 cyruscyrus   256 20 Apr 10:45 ptclient
drwxrws---  26 cyruscyrus  4096 29 Nov 2007  quota
drwxrws---   2 cyruscyrus   256 20 Apr 10:45 socket
-rw---   1 cyruscyrus139264 02 Sep 12:03 tls_sessions.db
drwx--  26 cyruscyrus  4096 30 Nov 2007  user

But the DB_CONFIG setting seemed not to be active.

:/mail/imap # db_stat -m -h db
641KB 604B  Total cache size.
1   Number of caches.
648KB   Pool individual cache size.
0   Requested pages mapped into the process' address space.
53M Requested pages found in the cache (96%).
2318503 Requested pages not found in the cache.
23  Pages created in the cache.
2318494 Pages read into the cache.
1311629 Pages written from the cache to the backing file.
1479063 Clean pages forced from the cache.
839315  Dirty pages forced from the cache.
0   Dirty pages written by trickle-sync thread.
158 Current total page count.
89  Current clean page count.
69  Current dirty page count.
67  Number of hash buckets used for page location.
57M Total number of times hash chains searched for a page.
15  The longest hash chain searched for a page.
177MTotal number of hash buckets examined for page location.
128MThe number of hash bucket locks granted without waiting.
1030The number of hash bucket locks granted after waiting.
297 The maximum number of times any hash bucket lock was waited for.
12M The number of region locks granted without waiting.
1747The number of region locks granted after waiting.
2318893 The number of page allocations.
4713896 The number of hash buckets examined during allocations
5   The max number of hash buckets examined for an allocation
2318377 The number of pages examined during allocations
2   The max number of pages examined for an allocation
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: /mail/imap/ptclient/ptscache.db
4096Page size.
0   Requested pages mapped into the process' address space.
9465518 Requested pages found in the cache (92%).
809878  Requested pages not found in the cache.
23  Pages created in the cache.
809878  Pages read into the cache.
279900  Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: /mail/imap/deliver.db
4096Page size.
0   Requested pages mapped into the process' address space.
41M Requested pages found in the cache (97%).
1443266 Requested pages not found in the cache.
0   Pages created in the cache.
1443257 Pages read into the cache.
957015  Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: /mail/imap/tls_sessions.db
4096Page size.
0   Requested pages mapped into the process' address space.
1780221 Requested pages found in the cache (96%

Re: incremental squatter

[Sebastian Hagedorn]

--On 2. September 2009 14:30:18 +0200 Paolo Cravero  
wrote:



Is it just a documentation error, so incremental indexing does work in
2.3.14?


Yes, it does.
--
.:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:.
.:.Regionales Rechenzentrum (RRZK).:.
.:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:.

p7sckFeoLvaL7.p7s
Description: S/MIME cryptographic signature

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: incremental squatter

[Adam Tauno Williams]

On Wed, 2009-09-02 at 14:30 +0200, Paolo Cravero wrote:
> Perhaps it is a bug in the documentation.
> 'man squatter' in the DESCRIPTION says there's no incremental update:
> "Squatter creates an index of ALL messages in the mailbox, not just those 
> since the last time that it was run (i.e.,  it  does  NOT  do  incremental 
> updates)."
> but in the OPTIONS a "-i" switch mentions incremental.
> Is it just a documentation error, so incremental indexing does work in 2.3.14?

It may be a matter of interpretation.


Squatter creates an index of ALL messages in the mailbox, not just those
since time that it was run (i.e., it does NOT do incremental updates).
Any messages appended  to  the mailbox after squatter is run, will NOT
be included in the index. To include new messages in the index, squatter
must be run again. 


I took "does NOT do incremental updates" to mean the index is not
updated on-the-fly when new messages enter the mailbox, only when
squatter is run.

-- 
OpenGroupware developer: awill...@whitemice.org

OpenGroupare & Cyrus IMAPd documenation @



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Migrating 32bit to 64bit Debian Lenny

[Bill Cameron]

Hi,

I've seen some questions about migrating from 32 bit to 64 bit. We
migrated last weekend and these are the steps we took.

Old server:
- rsync the cyrus data while cyrus is running
   rsync -vaH --delete -e ssh /var/lib/cyrus/ new-server:/var/lib/cyrus
   rsync -vaH --delete -e ssh /var/spool/cyrus/ new-server:/var/spool/cyrus
   rsync -vaH --delete -e ssh /var/spool/sieve/ new-server:/var/spool/sieve
- shut down cyrus
- repeat rsyncing of the three directories to provide stable
environment and databases. This will be a lot faster than the original
rsync.
- dump /var/lib/cyrus/mailboxes.db to a text file
   /usr/sbin/ctl_mboxlist -d > mboxlist.txt
- copy this text file to the new server

New server:
- make sure cyrus is shutdown
- switch to user 'cyrus'
   su - cyrus
- remove some of the databases
   rm /var/lib/cyrus/db/*
   rm /var/lib/cyrus/db.backup1/*
   rm /var/lib/cyrus/db.backup2/*
   rm /var/lib/cyrus/deliver.db
   rm /var/lib/cyrus/tls_sessions.db
   rm /var/lib/cyrus/mailboxes.db
- build new mailboxes.db from mboxlist.txt file
   /usr/sbin/ctl_mboxlist -u < mboxlist.txt
- check /var/log/mail.err and /var/log/mail.info for any errors
from the above command and the following commands. There should only
be one error about missing timestamp file but it is automatically
created.
- run the following commands and check logs for errors
   /usr/sbin/ctl_cyrusdb -r
  - the above command will verify mailboxes.db and annotations.db
   /usr/sbin/tls_prune
  - the above command will create a new tls_prune database
   /usr/sbin/ctl_cyrusdb -c
   /usr/sbin/cyr_expire -E 3
- you can also run the squatter command but it doesn't really need
to run until it's scheduled time. It takes a awhile to run.
- start cyrus and check that it is working correctly.
- you will need to reset any annotations (e.g.: expire) on
mailboxes/folders. We didn't have any annotations set on mailboxes so
I didn't try migrating that database.

The database types are defined in /etc/imapd.conf. They don't appear
in the default Lenny conf file since they use the predefined default
types. The man page for imapd.conf lists those defaults:
annotation_db: skiplist, duplicate_db: berkeley-nosync... The current
database types are listed in /usr/lib/cyrus/cyrus-db-types.active.

We had to take the server off-line to migrate some other applications
on the server so I didn't use imapsync. We are using imapsync to
migrate from Lotus Notes to cyrus.

Bill C.

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Migrating 32bit to 64bit Debian Lenny

[Simon Matter]

> Hi,
>
> I've seen some questions about migrating from 32 bit to 64 bit. We

Hi,

I understand that you also migrated to a newer OS and cyrus-imapd version,
right?

> migrated last weekend and these are the steps we took.
>
> Old server:
> - rsync the cyrus data while cyrus is running
>rsync -vaH --delete -e ssh /var/lib/cyrus/
> new-server:/var/lib/cyrus
>rsync -vaH --delete -e ssh /var/spool/cyrus/
> new-server:/var/spool/cyrus
>rsync -vaH --delete -e ssh /var/spool/sieve/
> new-server:/var/spool/sieve
> - shut down cyrus
> - repeat rsyncing of the three directories to provide stable
> environment and databases. This will be a lot faster than the original
> rsync.
> - dump /var/lib/cyrus/mailboxes.db to a text file
>/usr/sbin/ctl_mboxlist -d > mboxlist.txt
> - copy this text file to the new server
>
> New server:
> - make sure cyrus is shutdown
> - switch to user 'cyrus'
>su - cyrus
> - remove some of the databases
>rm /var/lib/cyrus/db/*
>rm /var/lib/cyrus/db.backup1/*
>rm /var/lib/cyrus/db.backup2/*
>rm /var/lib/cyrus/deliver.db
>rm /var/lib/cyrus/tls_sessions.db
>rm /var/lib/cyrus/mailboxes.db
> - build new mailboxes.db from mboxlist.txt file
>/usr/sbin/ctl_mboxlist -u < mboxlist.txt
> - check /var/log/mail.err and /var/log/mail.info for any errors
> from the above command and the following commands. There should only
> be one error about missing timestamp file but it is automatically
> created.
> - run the following commands and check logs for errors
>/usr/sbin/ctl_cyrusdb -r
>   - the above command will verify mailboxes.db and annotations.db
>/usr/sbin/tls_prune
>   - the above command will create a new tls_prune database
>/usr/sbin/ctl_cyrusdb -c
>/usr/sbin/cyr_expire -E 3
> - you can also run the squatter command but it doesn't really need
> to run until it's scheduled time. It takes a awhile to run.
> - start cyrus and check that it is working correctly.
> - you will need to reset any annotations (e.g.: expire) on
> mailboxes/folders. We didn't have any annotations set on mailboxes so
> I didn't try migrating that database.
>
> The database types are defined in /etc/imapd.conf. They don't appear
> in the default Lenny conf file since they use the predefined default
> types. The man page for imapd.conf lists those defaults:
> annotation_db: skiplist, duplicate_db: berkeley-nosync... The current
> database types are listed in /usr/lib/cyrus/cyrus-db-types.active.

I'm wondering how much of all this was really needed for the migration
from 32bit to 64bit? Are the BerkeleyDB ondisk files different on
32/64bit?

Because, the last migration I did was from RHEL3/32bit to RHEL5/64bit
using our own cyrus-imapd RPMs and the migration was as easy as stopping
cyrus-imapd, rsyncing /var/lib/imap + /var/spool/imap to the new box and
starting cyrus-imapd on the new box. Now, the RPMs do quite some magic on
the database files to make sure they are all skiplist after shutdown, and
switched back on startup. So my question remains, what parts of
cyrus-imapd are possibly arch dependant?

Regards,
Simon


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Migrating 32bit to 64bit Debian Lenny

[Pascal Gienger]

Simon Matter wrote:

> I'm wondering how much of all this was really needed for the migration
> from 32bit to 64bit? Are the BerkeleyDB ondisk files different on
> 32/64bit?

Yes they are. It's not the OS that matters but the architecture of the 
libdb4.so file.
It is still a good idea not to use Berkeley DB for real important data. 
Here at our university's cyrus we are using Berkeley for the duplicate 
delivery and the tls databases - both of them are easily set to zero in 
case of problems without deep impact on the functionality (in case the 
delivery db crashes users can get some mails two times (doubling), in 
the latter case (tls db crash) a returning client has to re-initiate a 
TLS handshake including key exchange).

Pascal Gienger
-- 
Pascal Gienger
University of Konstanz, IT Services Department ("Rechenzentrum")
Electronic Communications and Web Services
Building V, Room V404, Phone +49 7531 88 5048, Fax +49 7531 88 3739

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Migrating 32bit to 64bit Debian Lenny

[Bill Cameron]

> I'm wondering how much of all this was really needed for the migration
> from 32bit to 64bit? Are the BerkeleyDB ondisk files different on
> 32/64bit?
>

I initially tried just using rsync with cyrus shutdown on both servers
but cyrus failed to start on the new server due to db errors. As
mentioned this is due to the architecture of the libdb4.so file.

Further testing showed which files worked and which ones didn't.

Bill C.

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Migrating 32bit to 64bit Debian Lenny

[Bron Gondwana]

On Wed, Sep 02, 2009 at 10:46:35AM -0600, Bill Cameron wrote:
> > I'm wondering how much of all this was really needed for the migration
> > from 32bit to 64bit? Are the BerkeleyDB ondisk files different on
> > 32/64bit?
> >
> 
> I initially tried just using rsync with cyrus shutdown on both servers
> but cyrus failed to start on the new server due to db errors. As
> mentioned this is due to the architecture of the libdb4.so file.
> 
> Further testing showed which files worked and which ones didn't.

Thankfully skiplist is immune to such nonsense and just keeps working
across any architecture or underlying version change (apart from a
couple of bugs that are only fixed in CVS at the moment - *sigh*)

We've recently switched to using skiplist even for deliver and
TLS databases.  It works fine.  Possibly not quite as efficient,
but we haven't noticed a difference in the load on the machines.

Though - I do wonder how many problems we've had with BDB were
caused by idled forking with an environment reference and then
closing it in the parent, causing the reference count to be
incorrect.  There's a patch for that in CVS too.

Bron.

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Logging region out of memory

[Harms Consulting IT support desk]

G'day Marc,

Marc Patermann wrote:
> Hi,
>
> I have IMAPd 2.2.12 and BDB 4.2.52:
>
> When I got:
>
> Sep  2 11:28:39 rzhs199 local6:warn|warning lmtpunix[1171642]: DBERROR
> db4: Logging region out of memory; you may need to increase its size
>   

I'm not good for a lot of help in this mailing list, but whenever 
DBERROR appears in the logs, the recommended solution is to change 
database formats away from Berkeley DB. Search this mail list for 
DBERROR and see this page in the wiki for more info:

http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/WhatDatabaseBackend

HTH,
Josh
> Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[1171642]: DBERROR:
> opening /mail/imap/ptclient/ptscache.db: Not enough space
> Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[1171642]: DBERROR:
> opening /mail/imap/ptclient/ptscache.db: cyrusdb error
>
> Sep  2 11:28:39 rzhs199 local6:warn|warning lmtpunix[4227234]: DBERROR
> db4: Logging region out of memory; you may need to increase its size
> Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[4227234]: DBERROR:
> opening /mail/imap/deliver.db: Not enough space
> Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[4227234]: DBERROR:
> opening /mail/imap/deliver.db: cyrusdb error
> Sep  2 11:28:39 rzhs199 local6:err|error lmtpunix[4227234]: FATAL:
> lmtpd: unable to init duplicate delivery database
>
> Mass mail could not be delivered in time because LMTP had errors.
>
> I found DB_CONFIG in /mail/imap/
>
> :/mail/imap # cat DB_CONFIG
> set_cachesize 0 8388608 8
> set_lg_regionmax 524288
> set_lg_bsize 2097152
>
> and these files
>
> :/mail/imap # l
> 45888 insgesamt
> drwxr-xr-x  12 cyruscyrus  4096 02 Sep 12:00 .
> drwxr-xr-x   6 cyruscyrus   256 28 Jun 2007  ..
> -rw---   1 cyruscyrus   144 02 Sep 12:03 annotations.db
> drwxrws---   2 cyruscyrus  4096 02 Sep 04:14 db
> drwx--   2 cyruscyrus   256 02 Sep 11:44 db.backup1
> drwx--   2 cyruscyrus   256 02 Sep 11:14 db.backup2
> -rw-r--r--   1 cyruscyrus72 08 Jan 2009  DB_CONFIG
> -rw---   1 cyruscyrus  21336064 02 Sep 12:03 deliver.db
> drwxr-xr-x   2 root system  256 29 Nov 2007  lost+found
> -rw---   1 cyruscyrus   1106000 02 Sep 12:03 mailboxes.db
> -rw-rw   1 cyruscyrus689810 02 Sep 11:37 mailboxes.tsm
> -rw-r-   1 root system8 20 Apr 10:45 master.pid
> drwxrws---   2 cyruscyrus   256 29 Nov 2007  msg
> drwxrws---   2 cyruscyrus102400 02 Sep 12:04 proc
> drwxrws---   2 cyruscyrus   256 20 Apr 10:45 ptclient
> drwxrws---  26 cyruscyrus  4096 29 Nov 2007  quota
> drwxrws---   2 cyruscyrus   256 20 Apr 10:45 socket
> -rw---   1 cyruscyrus139264 02 Sep 12:03 tls_sessions.db
> drwx--  26 cyruscyrus  4096 30 Nov 2007  user
>
> But the DB_CONFIG setting seemed not to be active.
>
> :/mail/imap # db_stat -m -h db
> 641KB 604B  Total cache size.
> 1   Number of caches.
> 648KB   Pool individual cache size.
> 0   Requested pages mapped into the process' address space.
> 53M Requested pages found in the cache (96%).
> 2318503 Requested pages not found in the cache.
> 23  Pages created in the cache.
> 2318494 Pages read into the cache.
> 1311629 Pages written from the cache to the backing file.
> 1479063 Clean pages forced from the cache.
> 839315  Dirty pages forced from the cache.
> 0   Dirty pages written by trickle-sync thread.
> 158 Current total page count.
> 89  Current clean page count.
> 69  Current dirty page count.
> 67  Number of hash buckets used for page location.
> 57M Total number of times hash chains searched for a page.
> 15  The longest hash chain searched for a page.
> 177MTotal number of hash buckets examined for page location.
> 128MThe number of hash bucket locks granted without waiting.
> 1030The number of hash bucket locks granted after waiting.
> 297 The maximum number of times any hash bucket lock was waited for.
> 12M The number of region locks granted without waiting.
> 1747The number of region locks granted after waiting.
> 2318893 The number of page allocations.
> 4713896 The number of hash buckets examined during allocations
> 5   The max number of hash buckets examined for an allocation
> 2318377 The number of pages examined during allocations
> 2   The max number of pages examined for an allocation
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Pool File: /mail/imap/ptclient/ptscache.db
> 4096Page size.
> 0   Requested pages mapped into the process' address space.
> 9465518 Requested pages found in the cache (92%).
> 809878  Requested pages not found in the cache.
> 23  Pages created in the cache.
> 809878  Pages read into the cache.
> 279900  Pages written from the cache to the backing file.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Resources for MUA support of IMAP features?

[Wil Cooley]

Does anyone know of a mailing list or a web site with information about
MUA support of various IMAP features? For example, for IMAP IDLE the
Wikipedia entry is good:
  http://en.wikipedia.org/wiki/IMAP_IDLE

(Although it is lacking in some details about what to expect from a
server supporting it, especially server-specific information such as
using idled vs not.)

Or something like this (probably dated) reference about server features:
 http://www.melnikov.ca/mel/devel/ServerReference.html

The UW lists at http://www.washington.edu/imap/ seem (imap-use@
especially) like they would be an appropriate place, but they seem
kinda... dead.

Wil



signature.asc
Description: OpenPGP digital signature

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Logging region out of memory

[Pascal Gienger]

Marc Patermann wrote:
> Hi,
> 
> I have IMAPd 2.2.12 and BDB 4.2.52:
> 
> When I got:
> 
> Sep  2 11:28:39 rzhs199 local6:warn|warning lmtpunix[1171642]: DBERROR
> db4: Logging region out of memory; you may need to increase its size

Increase logging region size.

> I found DB_CONFIG in /mail/imap/
> 
> :/mail/imap # cat DB_CONFIG
> set_cachesize 0 8388608 8
> set_lg_regionmax 524288
> set_lg_bsize 2097152
> 
> and these files

The file DB_CONFIG has to be in the "db" subdirectory (/mail/imap/db in 
your case).
Be warned: Some parameters of DB_CONFIG also change the on-disk-format, 
so backup your db files before (after shutting down cyrus) and restart 
after your changes.

Don't delete "skipstamp" in this db directory as it is used by your 
skiplist databases.

Just a personal biased hint:
You should not use Berkeley DB for important data of your cyrus system. 
Berkeley has a very rapid random read performance which is important (in 
our case) with the duplicate delivery database (now 1,3 GB in size). But 
even that should be feasible with skiplist.

Pascal
-- 
Pascal Gienger
University of Konstanz, IT Services Department ("Rechenzentrum")
Electronic Communications and Web Services
Building V, Room V404, Phone +49 7531 88 5048, Fax +49 7531 88 3739

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Resources for MUA support of IMAP features?

[Paolo Cravero]

Wil Cooley wrote:
> Does anyone know of a mailing list or a web site with information about
> MUA support of various IMAP features? For example, for IMAP IDLE the

I once came across this wiki:
http://www.imapwiki.org/

that links to this http://uplib.parc.com/misc/imapclients.html for your 
specific question.

HTH,
Paolo

PS: nice domain name Wil :)


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html