Is "reconstruct -V max..." needed when upgrading from 2.5.10 to 3.0.7?

Nic Bernstein nic at onlight.com
Tue Jul 31 11:42:20 EDT 2018


Friends,
I'm preparing for a couple of belated 2.5.X to 3.0.X upgrades, and have 
a question about how necessary it is to run "reconstruct -V max" on the 
mailstore.  Both systems are currently running 2.5.10, and are already 
at index version 13.  However, when performing "reconstruct -V max" on 
one, on a new 3.0.7 (with patches) system, I see this:

    root at newmail:~# /usr/lib/cyrus/bin/reconstruct -V max user/onlight
    user.onlight uid 1 rediscovered - appending
    user.onlight uid 2 rediscovered - appending
    user.onlight uid 3 rediscovered - appending
    user.onlight uid 4 rediscovered - appending
    user.onlight uid 5 rediscovered - appending
    user/onlight
    Repacked user/onlight to version 13

The last line can be ignored, as it's really a noop.  The "rediscovered 
- appending" stuff is what catches my eye.  However, once the 
reconstruct is complete, here's what the mailbox looks like:

    root at newmail:/var/spool/cyrus/mail/I/user/onlight# /usr/lib/cyrus/bin/cyrdump user/onlight
    Content-Type: multipart/related; boundary="dump-27466-1533049817-351841533"

    --dump-27466-1533049817-351841533
    Content-Type: text/xml
    IMAP-Dump-Version: 0

    <imapdump uniqueid="710a47ca47ebc676">
       <mailbox-url>imap://newmail.example.com/user.onlight</mailbox-url>
       <incremental-uid>0</incremental-uid>
       <nextuid>15</nextuid>

    *<uidlist>6 7 9 10 11 12 13 14 </uidlist>*

       <flags>
    ...

Note that the <uidlist> doesn't list those low number UIDs which were 
listed in the reconstruct sequence.  In other words, I think this all is 
harmless, but I'm not sure how much overhead it brings to the whole 
process.

One of the servers has a total of 70GB of mail, so a complete 
reconstruct run only takes a short while.  The other, however, has over 
8TB scattered over >30 partitions.  If I could avoid running reconstruct 
across that whole wad, it'd be great.

Thoughts please?
     -nic

-- 
Nic Bernstein                             nic at onlight.com
Onlight, Inc.                             www.onlight.com
6525 W Bluemound Road, Suite 24           v. 414.272.4477
Milwaukee, Wisconsin  53213-4073

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20180731/cd2627b8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nic.vcf
Type: text/x-vcard
Size: 278 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20180731/cd2627b8/attachment.vcf>


More information about the Info-cyrus mailing list