<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 07/31/2018 02:32 PM, Savvas Karagiannidis wrote:<br>
    <blockquote type="cite"
cite="mid:CADfvMFNOd0FLgA+aFcniTyUbUWb+48eeQtekhk_G6L-8zz5vcw@mail.gmail.com">
      <div dir="ltr">
        <div>Hi Nic,</div>
        <div>as far as I know there are currently a couple of nasty open
          issues when upgrading old mailboxes, created from earlier
          versions of cyrus, that have not been upgraded to v13 index
          using reconstruct. These issues are:</div>
        <div><br>
        </div>
        <div><a
            href="https://github.com/cyrusimap/cyrus-imapd/issues/2171"
            moz-do-not-send="true">https://github.com/cyrusimap/cyrus-imapd/issues/2171</a></div>
        <div><a
            href="https://github.com/cyrusimap/cyrus-imapd/issues/2208"
            moz-do-not-send="true">https://github.com/cyrusimap/cyrus-imapd/issues/2208</a></div>
        <div><br>
        </div>
        <div>The main problem is frequent crashes with error message
          "assertion failed" when accessing these mailboxes.</div>
        <div><br>
        </div>
        <div>In issue #2208 a reconstruct command was proposed as a
          workaround:</div>
        <div>
          <code>reconstruct -G -V max [mailboxname]</code> <br>
        </div>
        <div><br>
        </div>
        <div>Note that -G parameter seems necessary, otherwise the
          problem persists...</div>
        <div><br>
        </div>
        <div>Note also, that this should be done while still in version
          2.5.x! The behavior of version 3.x reconstruct is not the same
          and you will not have the same results.</div>
        <div><br>
        </div>
        <div>As for the cyrdump you mention, it would be better if you
          compared the results before running reconstruct and after
          that.</div>
        <div> I guess what you would see is that the uidlist before
          would probably be in the range 6 - 9 (or you'd see a crash).
          cyrus 3.0.x considers that part of the index corrupt so simply
          cannot access those uids (1-5). Reconstruct detects this issue
          and what it does is that <b>reappends </b>those "newly
          found" messages, giving them a new uid, so that's what uids
          10-14 probably really are. Note that this causes these
          messages to appear unread, since they have no flags (not
          something you want for your clients' mailboxes).</div>
        <div><br>
        </div>
        <div>Bron mentioned something about this bug in the cyrus devel
          list a few days ago:</div>
        <div><a
href="https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/thread.html#4313"
            moz-do-not-send="true">https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/thread.html#4313</a><br>
        </div>
        <div>but I didn't see any related commit or anything mentioned
          in the above issues, so I'm not sure if there is a fix at the
          moment...</div>
      </div>
    </blockquote>
    <br>
    [Cross posting to cyrus-devel, as am now dumping core]<br>
    <br>
    Savvas,<br>
    Thanks for your response.  I think, however, that we've already
    tackled the issue of assert failures in reconstruct.  If you follow
    the entire thread of the message you linked to, Bron's message from
    the other day, he was actually writing to me, and his patch,
    referenced with a commit, within that message, worked just fine for
    me, as addressed in my follow up:<br>
       
    <a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/004315.html">https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-July/004315.html</a><br>
    <br>
    But I can see that you're correct about the cyrdump issue.  That's a
    real mess.  Here's the top of a cyrdump from the old host, running
    2.5.10:<br>
    <blockquote>
      <pre>onlight@mail:~$ sudo su cyrus -c "/usr/lib/cyrus/bin/cyrdump user.onlight" | head -12
Content-Type: multipart/related; boundary="dump-10426-1533070392-23406623"

--dump-10426-1533070392-23406623
Content-Type: text/xml
IMAP-Dump-Version: 0

<imapdump uniqueid="710a47ca47ebc676">
  <mailbox-url>imap://mail.ahwi.us/user.onlight</mailbox-url>
  <incremental-uid>0</incremental-uid>
  <nextuid>10</nextuid>

  <uidlist>1 2 3 4 5 6 7 9 </uidlist>
</pre>
    </blockquote>
    which comports with the existing mailbox directory:<br>
    <blockquote>
      <pre>onlight@mail:~$ sudo ls /var/spool/cyrus/mail/I/user/onlight/
1.  2.  3.  4.  5.  6.  7.  8.  9.  cyrus.annotations  cyrus.cache  cyrus.header  cyrus.index  Drafts  Sent  Spam  Trash
</pre>
    </blockquote>
    And here's what it looks like after reconstructing on the new
    server:<br>
    <blockquote>
      <pre>root@newmail:~# ls /var/spool/cyrus/mail/I/user/onlight/
10.  11.  12.  13.  14.  6.  7.  8.  9.  cyrus.annotations  cyrus.cache  cyrus.header  cyrus.index  Drafts  Sent  Spam  Trash
</pre>
    </blockquote>
    But I cannot even run cyrdump on the new mailbox now, I keep dumping
    core with a Floating Point error:<br>
    <blockquote>
      <pre>root@newmail:~# /usr/lib/cyrus/bin/cyrdump user/onlight
Content-Type: multipart/related; boundary="dump-27702-1533070740-1079351705"

--dump-27702-1533070740-1079351705
Content-Type: text/xml
IMAP-Dump-Version: 0

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

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

  <flags>
Floating point exception (core dumped)
</pre>
    </blockquote>
    Here's a backtrace from gdb:<br>
    <blockquote>
      <pre>Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/cyrus/bin/cyrdump user/onlight'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x00007fcbc1057955 in hash_lookup (key=key@entry=0x7ffd75ae4610 "systemflags", 
    table=table@entry=0x7fcbc1894e30 <attrs_by_name>) at lib/hash.c:159
159     lib/hash.c: No such file or directory.
(gdb) bt
#0  0x00007fcbc1057955 in hash_lookup (key=key@entry=0x7ffd75ae4610 "systemflags", 
    table=table@entry=0x7fcbc1894e30 <attrs_by_name>) at lib/hash.c:159
#1  0x00007fcbc1636822 in search_attr_find (name=<optimized out>) at imap/search_expr.c:2465
#2  0x000055c087d5a694 in systemflag_match (flag=1) at imap/cyrdump.c:149
#3  0x000055c087d5a9dd in dump_me (data=<optimized out>, rock=0x7ffd75ae68e0) at imap/cyrdump.c:209
#4  0x00007fcbc16164c3 in find_cb (rockp=rockp@entry=0x7ffd75ae6820, 
    key=key@entry=0x7fcbc1aa1a28 <error: Cannot access memory at address 0x7fcbc1aa1a28>, keylen=keylen@entry=12, 
    data=data@entry=0x7fcbc1aa1a38 <error: Cannot access memory at address 0x7fcbc1aa1a38>, datalen=<optimized out>)
    at imap/mboxlist.c:2410
#5  0x00007fcbc131f553 in myforeach (db=0x55c0894b2610, prefix=0x7ffd75ae5fb0 "user.onlight", prefixlen=0, 
    goodp=0x7fcbc16162c0 <find_p>, cb=0x7fcbc1616390 <find_cb>, rock=0x7ffd75ae6820, tidptr=<optimized out>)
    at lib/cyrusdb_skiplist.c:1177
#6  0x00007fcbc16141cd in mboxlist_find_category (rock=rock@entry=0x7ffd75ae6820, 
    prefix=prefix@entry=0x7ffd75ae5fb0 "user.onlight", len=len@entry=0) at imap/mboxlist.c:2685
#7  0x00007fcbc1614b2c in mboxlist_do_find (rock=rock@entry=0x7ffd75ae6820, patterns=patterns@entry=0x55c0894b26f0)
    at imap/mboxlist.c:2877
#8  0x00007fcbc1619fe6 in mboxlist_findallmulti (namespace=<optimized out>, patterns=0x55c0894b26f0, isadmin=<optimized out>, 
    userid=0x0, auth_state=<optimized out>, proc=<optimized out>, rock=0x7ffd75ae68e0) at imap/mboxlist.c:2942
#9  0x000055c087d5a4bd in main (argc=2, argv=<optimized out>) at imap/cyrdump.c:119
</pre>
    </blockquote>
    I'll note, too, that the behavior of reconstruct, with regards to
    those low numbered UIDs, is totally inconsistent.  Here's a re-run
    on the same mailbox, after re-rsyncing (with --delete option) from
    the original server:<br>
    <blockquote>
      <pre>root@newmail:~# su cyrus -c "/usr/lib/cyrus/bin/reconstruct -V max user/onlight"
user.onlight: update uniqueid from header (null) => 710a47ca47ebc676
user.onlight updating quota_mailbox_used: 10715 => 3910
user.onlight: updating exists 8 => 3
user.onlight: updating sync_crc 2250269913 => 1705867986
user/onlight
Repacked user/onlight to version 13
root@newmail:~# ls -l /var/spool/cyrus/mail/I/user/onlight/
total 76
-rw------- 1 cyrus mail  2924 Mar 27  2008 1.
-rw------- 1 cyrus mail   748 Mar 27  2008 2.
-rw------- 1 cyrus mail   804 Jul 15  2008 3.
-rw------- 1 cyrus mail  1137 Oct  2  2009 4.
-rw------- 1 cyrus mail  1192 Apr 22  2012 5.
-rw------- 1 cyrus mail  1423 Sep 19  2016 6.
-rw------- 1 cyrus mail  1743 Dec 22  2016 7.
-rw------- 2 cyrus mail  1357 Jun  1  2017 8.
-rw------- 1 cyrus mail   744 Jun  1  2017 9.
-rw------- 1 cyrus mail   336 Mar  1  2017 cyrus.annotations
-rw------- 1 cyrus mail 10276 Jul 31 15:54 cyrus.cache
-rw------- 1 cyrus mail   165 Feb 28  2017 cyrus.header
-rw------- 1 cyrus mail  1064 Jul 31 16:16 cyrus.index
drwx------ 2 cyrus mail  4096 Nov 30  2017 Drafts
drwx------ 2 cyrus mail  4096 Nov 30  2017 Sent
drwx------ 2 cyrus mail  4096 Nov 30  2017 Spam
drwx------ 2 cyrus mail  4096 Nov 30  2017 Trash
</pre>
    </blockquote>
    So now it's just ignoring UIDs 1-6, and claiming the mailbox has
    just 3 messages.<br>
    <br>
    Color me confused.<br>
    <br>
    Honestly, I am not sure how anyone is managing large upgrades from
    2.5 to 3.0?  Not being able to reliably bring the existing message
    store up to the necessary level is quite unsettling.<br>
    <br>
    Cheers,<br>
        -nic<br>
    <br>
    <blockquote type="cite"
cite="mid:CADfvMFNOd0FLgA+aFcniTyUbUWb+48eeQtekhk_G6L-8zz5vcw@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Hope this helps,</div>
        <div>Regards,</div>
        <div>Savvas Karagiannidis<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Tue, Jul 31, 2018 at 6:43 PM Nic Bernstein
          <<a href="mailto:nic@onlight.com" moz-do-not-send="true">nic@onlight.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text="#000000" bgcolor="#FFFFFF"> Friends,<br>
            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:<br>
            <blockquote>
              <pre>root@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</pre>
            </blockquote>
            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:<br>
            <blockquote>
              <pre>root@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><a class="moz-txt-link-freetext" href="imap://">imap://</a><a href="http://newmail.example.com/user.onlight" target="_blank" moz-do-not-send="true">newmail.example.com/user.onlight</a></mailbox-url>
  <incremental-uid>0</incremental-uid>
  <nextuid>15</nextuid>

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

  <flags>
...
</pre>
            </blockquote>
            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. <br>
            <br>
            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.<br>
            <br>
            Thoughts please?<br>
                -nic<br>
            <pre class="m_4724969770412079391moz-signature" cols="72">-- 
Nic Bernstein                             <a class="m_4724969770412079391moz-txt-link-abbreviated" href="mailto:nic@onlight.com" target="_blank" moz-do-not-send="true">nic@onlight.com</a>
Onlight, Inc.                             <a class="m_4724969770412079391moz-txt-link-abbreviated" href="http://www.onlight.com" target="_blank" moz-do-not-send="true">www.onlight.com</a>
6525 W Bluemound Road, Suite 24           v. 414.272.4477
Milwaukee, Wisconsin  53213-4073
</pre>
          </div>
          ----<br>
          Cyrus Home Page: <a href="http://www.cyrusimap.org/"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.cyrusimap.org/</a><br>
          List Archives/Info: <a
            href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br>
          To Unsubscribe:<br>
          <a
            href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></blockquote>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Nic Bernstein                             <a class="moz-txt-link-abbreviated" href="mailto:nic@onlight.com">nic@onlight.com</a>
Onlight, Inc.                             <a class="moz-txt-link-abbreviated" href="http://www.onlight.com">www.onlight.com</a>
6525 W Bluemound Road, Suite 24           v. 414.272.4477
Milwaukee, Wisconsin  53213-4073
</pre>
  </body>
</html>