ctl_cyrusdb -r performance over NFS

[Andrew McNamara]

>> We've noticed that "ctl_cyrusdb -r" is quite slow when working against an
>> NFS spool (Netapp) on an otherwise quiesent system. Looking at a gcore,
>> I see that the slow part is preening the mailboxes (deleting reserved
>> mailboxes), rather than rolling the checkpoints forward. The process
>> is looping doing stat(), fstat() and fcntl(F_SETLKW) calls, the last
>> of which in the case of NFS requires a round-trip to the server, and I
>> suspect this is where the slowdown comes from.
>
>You probably don't want to be running cyrus on an NFS partition.

The only other option would be a SAN, and people here trust them even
less.  BTW, they've successfully been running a large, heavily used,
Oracle instance for several years now over NFS to a Netapp with several
terabytes of storage, which surprised me.

We're in the process of doing some agressive testing on the resulting mail
system to find out if it corrupts messages under load, etc.

>> Running ctl_cyrusdb with -x option results in near-instantaneous startups.
>> What are mailbox reservations used for, and what side-effects will we see
>> running with -x?
>>
>> The only other answer I see is to modify ctl_cyrusdb so that it avoids
>> locking the mailboxes.db for each row, but rather aquires a "table lock".
>> This may require an intrusive modification to the db api.
>
>Reserved mailboxes will pop up after a crash halfway through a create, you
>then won't be able to access that mailbox name until the reservation is
>cleared.

Okay - that's what I wanted to know. Can a mailbox be "unreservered"
via an admin login - could I get the user creation script to detect a
stale reservation and try again?

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/