<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 06/12/2018 11:17, Ismaël Tanguy
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:b4aca0ea-a981-cbd7-edf1-1d4b55509967@univ-brest.fr">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>Hello,</p>
      <p>thanks for your answer.<br>
        We have been using for more than 10 years Cyrus with NFS because
        of the snapshot.<br>
        Snapshot give a way to restore mail or mailbox.<br>
        It has worked like a charm until the migration.<br>
        Now we're stuck on daily mailbox corruption due to this storage.</p>
    </blockquote>
    <br>
    <br>
    Ismaël,<br>
    <br>
    <br>
    <br>
    In the course of the past years there have been quite a few remarks
    made on this list regarding succesful use of NFS as a Cyrus mail
    spool.<br>
    <br>
    You stated yourself that the problems started when switching from
    one type of NFS server to another.<br>
    You may want to have a close(r) look at the way you mount the NFS
    share(s) on the Cyrus server(s).<br>
    <br>
    <br>
    I am looking at moving to NFS storage for (approx. 10 TB) Cyrus
    spool in the course of 2019 but intend to keep the metadata
    (header/index/cache) on an SSD pool local to the (virtual) Cyrus
    server. Haven't decided yet whether we'll move from 2.3 to 2.5 or
    3.0, certainly not 2.4<br>
    <br>
    <br>
    <br>
    Eric Luyten.<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:b4aca0ea-a981-cbd7-edf1-1d4b55509967@univ-brest.fr">
      <p>We're looking, first, to a way to automate safely the
        reconstruct of mailbox, ideally keeping the Seen State of mails.<br>
        In parrellel, we're studying the migration to Cyrus 2.4.17
        without the use of NFS.</p>
      Cheers,<br>
      Ismael
      <div class="moz-signature"><a href="http://www.univ-brest.fr"
          moz-do-not-send="true"> </a>
        <p style="font-family:Arial; font-size:10px;"><br>
        </p>
      </div>
      <div class="moz-cite-prefix">Le 06/12/2018 à 08:21, <a
          class="moz-txt-link-abbreviated"
          href="mailto:egoitz@sarenet.es" moz-do-not-send="true">egoitz@sarenet.es</a>
        a écrit :<br>
      </div>
      <blockquote type="cite"
        cite="mid:07C7ED81-6704-48FB-B842-ED8727D7559C@sarenet.es">
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8">
        Hi!
        <div><br>
        </div>
        <div>Mate nfs, is no tan appropiate storage for Cyrus. I’d
          recommend you using machine local storage. Using that kind of
          config won’t success.</div>
        <div><br>
        </div>
        <div>Cheers,<br>
          <br>
          <div id="AppleMailSignature" dir="ltr">Egoitz,</div>
          <div dir="ltr"><br>
            El 5 dic 2018, a las 12:13, Ismaël Tanguy <<a
              href="mailto:ismael.tanguy@univ-brest.fr"
              moz-do-not-send="true">ismael.tanguy@univ-brest.fr</a>>
            escribió:<br>
            <br>
          </div>
          <blockquote type="cite">
            <div dir="ltr">
              <meta http-equiv="content-type" content="text/html;
                charset=utf-8">
              <p>Hello, this is a Cyrus 2.3.11 on Centos 5.<br>
                About 5000 users for 10 To.<br>
              </p>
              <p>Mail storage has been moved from NetApp NFS to FluidsFS
                (aka Dell Compellent NFS).<br>
                Since an update on FluidFS, Imap spool undergoes daily
                NFS timeouts which leads to corrupt mailboxes.<br>
                Typically, this begins with lines like this in
                /var/log/messages:</p>
              <pre>Dec  5 09:54:43 mailhost kernel: lockd: server 192.xxx.xx.xx not responding, timed out

</pre>
              <p>Which is followed by IOERROR for accessed mailboxes
                during NFS timeout:</p>
              <pre>Dec  5 09:54:47 mailhost lmtpunix[14542]: IOERROR: locking index for user.xxxx: Input/output error
Dec  5 09:54:47 mailhost imaps[21999]: IOERROR: locking header for user.xxxx.Sent: Input/output error
Dec  5 09:54:47 mailhost imaps[26935]: IOERROR: locking index for user.xxxx: Input/output error
Dec  5 09:54:47 mailhost imaps[24013]: IOERROR: locking index for user.xxxx: Input/output error
Dec  5 09:54:47 mailhost imaps[15672]: IOERROR: locking index for user.xxxx: Input/output error
Dec  5 09:54:47 mailhost imaps[3999]: IOERROR: locking index for user.xxxx: Input/output error
Dec  5 09:54:47 mailhost imaps[30671]: IOERROR: locking index for user.xxxx: Input/output error</pre>
              <p>...................<br>
                Around 15 maiboxes are corrupted at each timeouts.<br>
                Manually, we can repair this mailbox:</p>
              <ul>
                <li>first, we have to delete all cyrus files in mailbox,
                  if not the following reconstruct can be blocked</li>
                <li>then, we reconstruct the mailbox (reconstruct -s
                  user.<NAME>.<FOLDER><br>
                </li>
              </ul>
              <p>The downside of this method is that all messages in the
                reconstructed folder are marked 'Not seen'.<br>
                To automate this, a Python script has been written, but
                sometimes not all cyrus files (cyrus.index) are
                recreated:<br>
              </p>
              <pre>Dec  5 01:03:53 mailhost lmtpunix[497]: IOERROR: opening /var/spool/imap/x/user/xxxxxx/cyrus.index: No such file or directory</pre>
              <p>Timeouts happen about 3 times per day, and cyrus
                deliver process is blocked when delivering to a
                corrupted mailbox.<br>
                So my first question is : how can we reconstruct a
                mailbox without marking mails as not seen?<br>
                And my second question is : why cyrus files are not
                recreated everytime? Is this due to the -s parameter
                with reconstruct?<br>
              </p>
              <p>Any help will be appreciated.</p>
              <p>Thanks</p>
              <p>------------------</p>
              <p>Ismael TANGUY<br>
              </p>
              <div class="moz-signature">-- <br>
                <a href="http://www.univ-brest.fr"
                  moz-do-not-send="true"> </a>
                <p style="font-family:Arial; font-size:10px;"><br>
                </p>
              </div>
            </div>
          </blockquote>
          <blockquote type="cite">
            <div dir="ltr"><span>----</span><br>
              <span>Cyrus Home Page: <a
                  href="http://www.cyrusimap.org/"
                  moz-do-not-send="true">http://www.cyrusimap.org/</a></span><br>
              <span>List Archives/Info: <a
                  href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/"
                  moz-do-not-send="true">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a></span><br>
              <span>To Unsubscribe:</span><br>
              <span><a
                  href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus"
                  moz-do-not-send="true">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></span><br>
            </div>
          </blockquote>
        </div>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">----
Cyrus Home Page: <a class="moz-txt-link-freetext" href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a>
List Archives/Info: <a class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
    </blockquote>
    <br>
  </body>
</html>