34/8939b308e764eda424b32f72aed575acfc69cc

   1 Return-Path:\r
   2  <return-jmxwjhzeuidrb5in85caytaxb2@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6  by arlo.cworth.org (Postfix) with ESMTP id 4EB406DE13DB\r
   7  for <notmuch@notmuchmail.org>; Sun, 23 Aug 2015 13:06:30 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.261\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.590,\r
  13   RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001]\r
  14  autolearn=disabled\r
  15 Received: from arlo.cworth.org ([127.0.0.1])\r
  16  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17  with ESMTP id AVNoyFJljYQs for <notmuch@notmuchmail.org>;\r
  18  Sun, 23 Aug 2015 13:06:28 -0700 (PDT)\r
  19 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  20  by arlo.cworth.org (Postfix) with ESMTPS id 5C0D76DE13DA\r
  21  for <notmuch@notmuchmail.org>; Sun, 23 Aug 2015 13:06:28 -0700 (PDT)\r
  22 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  23  [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  24  t7NK6LXZ024280; Sun, 23 Aug 2015 13:06:21 -0700 (PDT)\r
  25 Received: (from dm@localhost)\r
  26  by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7NK6KAv003545;\r
  27  Sun, 23 Aug 2015 13:06:20 -0700 (PDT)\r
  28 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  29  return-jmxwjhzeuidrb5in85caytaxb2@ta.scs.stanford.edu using -f\r
  30 From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
  31 To: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= <aidecoe@aidecoe.name>,\r
  32  notmuch@notmuchmail.org\r
  33 Subject: Re: muchsync files renames\r
  34 In-Reply-To: <871teu8kdd.fsf@freja.aidecoe.name>\r
  35 References: <878u93ujdo.fsf@freja.aidecoe.name>\r
  36  <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name>\r
  37 Reply-To: David Mazieres expires 2015-11-21 PST\r
  38  <mazieres-f72cdtyxmh2n26c2fbep99wgpw@temporary-address.scs.stanford.edu>\r
  39 Date: Sun, 23 Aug 2015 13:06:20 -0700\r
  40 Message-ID: <87oahxojlv.fsf@ta.scs.stanford.edu>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: text/plain; charset=utf-8\r
  43 Content-Transfer-Encoding: quoted-printable\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.18\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48  <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Sun, 23 Aug 2015 20:06:30 -0000\r
  57 \r
  58 Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:\r
  59 \r
  60 > Hi David,\r
  61 >\r
  62 > Fist of all thank you for such elaborate answer.\r
  63 >\r
  64 > I have missed the paragraph about maildir.synchronize_flags somehow.  I\r
  65 > have it enabled.  So this must be source of a problem (?).\r
  66 \r
  67 I've only ever tested with mailder.synchronize_flags =3D true, because I'm\r
  68 worried that if I disable it I will have a hard time re-enabling it.  I\r
  69 do think it is a source of inefficiency, but muchsync should still be\r
  70 usable.\r
  71 \r
  72 > Here follows steps I followed:\r
  73 >\r
  74 > 1. I initialized server locally with muchsync -vv.  My mail is stored in\r
  75 > ~/Mail on the server.\r
  76 > 2. I run muchsync --init ~/mail SERVER. (Directory names do not need to\r
  77 > be the same, do they?)\r
  78 \r
  79 Confirmed that directory names do not need to be the same.\r
  80 \r
  81 > 3. I run muchsync SERVER.\r
  82 > 4. When it lasted much longer then initialization I canceled it by\r
  83 > single SIGINT (^c).\r
  84 \r
  85 Interesting.  I wish I knew why this was taking much longer than running\r
  86 it on the server, and whether the delay was caused by client activity or\r
  87 server activity.\r
  88 \r
  89 I don't suppose you'd be willing to make a copy of your mail database to\r
  90 repeat the experiment without any risk of messing up your real maildir?\r
  91 Basically what would be interesting to see is (assuming .notmuch-copy on\r
  92 server is configured for this disposable copy):\r
  93 \r
  94     # Log everything for later analysis\r
  95     script\r
  96     # Use new config file location for disposable copy\r
  97     export NOTMUCH_CONFIG=3D$HOME/.notmuch-copy\r
  98     # Set up a new initial database\r
  99     muchsync -vvvv --init ~/test-copy SERVER -vvvv --config=3D.notmuch-copy\r
 100 \r
 101     # Now initial copy is made, see if client is slow\r
 102     # Is notmuch new itself slow?\r
 103     notmuch new\r
 104     # Is resynchronizing muchsync with notmuch slow?\r
 105     muchsync -vvvv\r
 106 \r
 107     # Now see if something weird happened on server to make notmuch new slow\r
 108     ssh SERVER notmuch --config=3D.notmuch-copy new\r
 109     # Now see if something weird happened on server to make muchsync slow\r
 110     ssh SERVER muchsync -vvvv --config=3D.notmuch-copy\r
 111 \r
 112     # Now finally try resynchronizing to see if this is slow\r
 113     muchsync -vvvv SERVER -vvvv --config=3D.notmuch-copy\r
 114     # Save script file\r
 115     exit\r
 116 \r
 117 Does something along these lines make sense?  If you can figure out\r
 118 which of these is slow (other than --init, which always will be), and\r
 119 what the verbose chatter is, that would help me narrow down and identify\r
 120 any problem.\r
 121 \r
 122 > 5. I rerun muchsync SERVER and then it notified me that notmuch\r
 123 > identified files names changes - more than 1000.\r
 124 \r
 125 Were the link changes on the client (sent) or the server (received)\r
 126 side?\r
 127 \r
 128 > 6. I waited a bit and then I canceled it by SIGINT.\r
 129 > 7. I run muchsync --noup SERVER. This took only seconds to finish.\r
 130 \r
 131 So this suggests the issue is on the client side.  It sounds like a bug.\r
 132 I wonder if I we can just reproduce this using a public email corpus, so\r
 133 we don't have to worry about people's private email.\r
 134 \r
 135 > I suspected that muchsync at step 3 and 5 tried to push files renames\r
 136 > back to server.  But now I am not sure what was going on.  Have I\r
 137 > desynchronized file mail flags?  It's hard to say if anything has broken\r
 138 > for me, but I am a bit worried anyway.\r
 139 >\r
 140 > If I just disable maildir.synchronize_flags and rerun muchsync, will\r
 141 > everything get synchronized properly?\r
 142 \r
 143 I don't think that will change things.  maildir.synchronized_flags will\r
 144 make things slower, but it shouldn't affect the SUMMARY numbers you see\r
 145 at the end of muchsync, other than maybe files moving from .../new to\r
 146 .../cur.  But presumably most of your mail files were already in cur\r
 147 directories.\r
 148 \r
 149 David\r