7d/1424312f61bc33f2654eeec1ea42b13939cf1d

   1 Return-Path:\r
   2  <return-tscnjiupa5jk2z8akbff4tt9se@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 344406DE1B1B\r
   7  for <notmuch@notmuchmail.org>; Sat, 22 Aug 2015 22:42:12 -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.208\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.643,\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 cd5ew9ssLEEv for <notmuch@notmuchmail.org>;\r
  18  Sat, 22 Aug 2015 22:42:09 -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 6C6FD6DE18EF\r
  21  for <notmuch@notmuchmail.org>; Sat, 22 Aug 2015 22:42:09 -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  t7N5g1Cj019244; Sat, 22 Aug 2015 22:42:01 -0700 (PDT)\r
  25 Received: (from dm@localhost)\r
  26  by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7N5g0Dj012017;\r
  27  Sat, 22 Aug 2015 22:42:00 -0700 (PDT)\r
  28 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  29  return-tscnjiupa5jk2z8akbff4tt9se@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: <878u93ujdo.fsf@freja.aidecoe.name>\r
  35 References: <878u93ujdo.fsf@freja.aidecoe.name>\r
  36 Date: Sat, 22 Aug 2015 22:41:59 -0700\r
  37 Message-ID: <876146o920.fsf@ta.scs.stanford.edu>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain; charset=utf-8\r
  40 Content-Transfer-Encoding: quoted-printable\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.18\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45  <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Sun, 23 Aug 2015 05:42:12 -0000\r
  54 \r
  55 Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:\r
  56 \r
  57 > Hi,\r
  58 >\r
  59 > I am testing muchsync-2 and it looks to me that files names across\r
  60 > machines are different.  Moreover when syncing again after\r
  61 > initialization it seems muchsync is working on something.  I have\r
  62 > canceled this and rerun muchsync.  notmuch reported lots of files\r
  63 > renames on server.  What and why it happens?\r
  64 \r
  65 What muchsync specifically synchronizes for messages in the mapping:\r
  66 \r
  67     (directory, SHA-1-hash, link-count)\r
  68 \r
  69 So if a directory contains two copies of a file on one machine, it will\r
  70 end up with two copies on the other machine.  However, the file names\r
  71 themselves are not the same, but rather are created in accordance with\r
  72 the maildir spec.  (Note SHA-1 wouldn't be my first choice of hash\r
  73 function, but notmuch already uses this for messages with long message\r
  74 IDs, so I figured I'd just be consistent with existing practice.)\r
  75 \r
  76 In terms of what muchsync is working on, you can run it with "-vvvv" on\r
  77 both sides to get an idea, as in "muchsync -vvvv server -vvvv".  Better\r
  78 yet, you can just run it on one side with "muchsync -vvvv".  You'll get\r
  79 a lot of output, so maybe run it inside the script command to save the\r
  80 output.maybe run it inside the script command to save the output.  If\r
  81 you have enabled maildir.synchronize_flags, it could be that notmuch is\r
  82 initially renaming all of your files, in which case muchsync needs to\r
  83 re-hash them to make sure they haven't changed.\r
  84 \r
  85 How did you cancel muchsync?  If you send it a single SIGINT or SIGTERM,\r
  86 it attempts to clean up after itself.  However, upon multiple signals or\r
  87 other signals, it immediately exits.  Muchsync is conservative about\r
  88 updating the database, to avoid missing tags or files that have been\r
  89 changed.  It always updates the notmuch database first, then its own\r
  90 sqlite database with a version number.  That means if you kill muchsync,\r
  91 some number of files may get picked up as changed again even though\r
  92 really they were just copied from a peer.\r
  93 \r
  94 To mitigate this problem, the muchsync client syncs the database every\r
  95 10 seconds, so that in theory you should only get 10 seconds of extra\r
  96 work from killing the client.  However, the server does not sync\r
  97 periodically, on the assumption that it is more likely to read an EOF\r
  98 than get killed, although currently it doesn't appear to commit any\r
  99 pending transactions to the sqlite database upon EOF, which may be an\r
 100 oversight.\r
 101 \r
 102 So to summarize:\r
 103 \r
 104   * File names are not the same across machine, only file contents and\r
 105     directory structure.\r
 106 \r
 107   * Give muchsync lots of "-v" options to see what it is doing.\r
 108 \r
 109   * Try to avoid killing muchsync.  Doing so is safe, but likely to\r
 110     generate extra work in the form of phantom renames or tag changes\r
 111     that get synchronized even though they don't need to be.\r
 112 \r
 113   * Possibly the server should handle EOF more gracefully and commit any\r
 114     pending transactions, or the client should periodically send a\r
 115     commit command to the server.\r
 116 \r
 117 If you think something is wrong, I can help you figure it out, but I\r
 118 need to know what maildir.synchronize_flags is set to on each replica,\r
 119 what you mean by "canceled", and roughly what was happening when you\r
 120 canceled (uploading or downloading).\r
 121 \r
 122 David\r