some notes on upgrading from 2.1.15 to 2.2.12

[Simon Matter]

> Simon Matter wrote:
>>> 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 et all,
>
> Our site had a huge failure (we lost the config directory /var/imap)
> this weekend.  We are now back running with a recovered mailboxes.db en
> *.sub files for our users (we didn't use reconstruct as that would take
> to long, 800Gigs of mail).
>
> The only thing still lacking is correct quotas.  I set the quota for
> each mailbox to 'none' (to get everything working).  Now I want to add a
> correct quota number.  However I can set it with 'sq user.login x'.  But
>   requesting the quota gives me:
> tarzan> lq user.rgevaert
>
>   STORAGE 0/2000000 (0%)
>
> I am sure to have several megabytes.  I looks like I have to run the
> quota program.

In my case running quota didn't help until I reconstructed the mailbox.
And I never tried to run quota -f with a mailbox-prefix. And then, I'm
running 2.3.7 while you run a much older version which could also make a
difference.

I recommend to run reconstruct first and then quota -f.

Simon

>
> Before doing it on the full system I would like to run it for my own
> mailbox.  But:
>
>       Running quota with both the  -f  option  and  mailbox-prefix
>       arguments is not recommended.
>
> I'm running:
>
> name       : Cyrus IMAPD
> version    : v2.1.18 2005/02/14 06:45:19
>
> Do you have any ideas what the consequences would be if I ran quota -f
> user.login on the running system?
>
> Thanks in advance,
> --
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Rudy Gevaert          Rudy.Gevaert at UGent.be          tel:+32 9 264 4734
> Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office
> Groep Systemen                    Systems group
> Universiteit Gent                 Ghent University
> Krijgslaan 281, gebouw S9, 9000 Gent, Belgie               www.UGent.be
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>