some notes on upgrading from 2.1.15 to 2.2.12

Simon Matter simon.matter at invoca.ch
Fri Nov 17 01:15:20 EST 2006


> This may not be too important for anyone any more, I had some weirdness
> with quotas wehn upgrading from 2.1.15 to 2.2.12.
>
> At first I thought that all my quotas were somehow lost during the
> upgrade.  Originally I thought this might have been because I
> inadvertently left the Cyrus master daemon turned on when I first
> rebooted the system back to multi-user mode.  It seemed as though the
> quotas.db file, was completely empty after the aborted run of the new
> version prior to DB conversion.  Hmmm....  hang on, maybe that's also
> because the old version had been configured to use quotalegacy by
> default, which are the individual files in /var/quota/?/user.*; but the
> new version was configured to use a skiplist DB by default, and the
> actual setting was never present in the config file.
>
> Not thinking about the quotalegacy issue (because I was too tired) I
> simply re-assigned the quotas manually using the cyradm interface, shut
> down master, then used "quota -f" to recover the usage numbers.  However
> during recovery I noted some very strange things happening with the
> "quota -f" runs.  The first time I ran "quota -f" without any mailboxes
> then it seemed to whack the usage numbers by a factor of two (I can't
> remember which way) on the mailboxes where I had already done a test run
> of "quota -f user.USER".

I saw things like that more than once and I never figured out what exactly
has triggered it and which versions of cyrus were affected. However, I
found a general rule which seems important at least it was so when I last
had a problem with quotas with 2.3.7:
Always make sure that your metadata is clean before using quota -f. If in
doubt, run reconstruct first. This seems to also be the case after some
upgrades. So for me I'm now always doing a reconstruct before a quota -f.
This can takes dozens of hours on large systems but better than having
broken quotas for such a long period.

Simon


More information about the Info-cyrus mailing list