27/5f4565af9b8f96627d545afd595205d3fd9914

   1 Return-Path:\r
   2  <return-yjfumptdmm9v8zs6su3fi692c6@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 olra.theworths.org (Postfix) with ESMTP id D6677421176\r
   7         for <notmuch@notmuchmail.org>; Fri, 11 Apr 2014 09:05:00 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.3\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
  13         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id oHihRs1iJvsa for <notmuch@notmuchmail.org>;\r
  17         Fri, 11 Apr 2014 09:04:56 -0700 (PDT)\r
  18 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 937E6421173\r
  22         for <notmuch@notmuchmail.org>; Fri, 11 Apr 2014 09:04:56 -0700 (PDT)\r
  23 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  24  [127.0.0.1])   by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  25  s3BG3c97012339;        Fri, 11 Apr 2014 09:03:38 -0700 (PDT)\r
  26 Received: (from dm@localhost)\r
  27         by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3BG3cFO000873;\r
  28         Fri, 11 Apr 2014 09:03:38 -0700 (PDT)\r
  29 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  30         return-yjfumptdmm9v8zs6su3fi692c6@ta.scs.stanford.edu using -f\r
  31 From: dm-list-email-notmuch@scs.stanford.edu\r
  32 To: David Bremner <david@tethera.net>, Gaute Hope <eg@gaute.vetsj.com>\r
  33 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
  34         changed on disk\r
  35 In-Reply-To: <87k3aw5dj5.fsf@zancas.localnet>\r
  36 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  37         <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
  38         <87wqexnqvb.fsf@ta.scs.stanford.edu>\r
  39         <87k3aw5dj5.fsf@zancas.localnet>\r
  40 Date: Fri, 11 Apr 2014 09:03:38 -0700\r
  41 Message-ID: <877g6v3lb9.fsf@ta.scs.stanford.edu>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: text/plain\r
  44 Cc: notmuch <notmuch@notmuchmail.org>\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 Reply-To: David Mazieres expires 2014-07-10 PDT\r
  49         <mazieres-7je64uqare55j4eig77r2axtva@temporary-address.scs.stanford.edu>\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51         <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Fri, 11 Apr 2014 16:05:01 -0000\r
  60 \r
  61 David Bremner <david@tethera.net> writes:\r
  62 \r
  63 >> Exactly.  It could be a tick, or just the current time of day if your\r
  64 >> clock does not go backwards.  (I'd be willing to do a full scan if the\r
  65 >> clock ever goes backwards.)  The advantage of time is that you don't\r
  66 >> have to synchronously update some counter.\r
  67 >\r
  68 > I think I'd lean towards global time so that one could use it to resolve\r
  69 > conflicts between changes to multiple copies of the database.\r
  70 \r
  71 I, too, would prefer to use time.  However, I'm doubtful it would help\r
  72 resolve conflicts.  On the plus side, I'm not sure it is even needed to\r
  73 resolve conflicts.  My mail synchronizer has an algorithm for resolving\r
  74 conflicts that always works without human intervention and in my limited\r
  75 experience does exactly what I want:\r
  76 \r
  77    * If there's a conflict between two replicas, ensure that each\r
  78      maildir ends up with the maximum number of the number copies of the\r
  79      message in each of the two databases being reconciled.  [Example:\r
  80      If replica A deletes a message and replica B moves it from folder\r
  81      INBOX to folder SPAM, you end up with a copy in spam.  If replica A\r
  82      moves a message to folder IMPORTANT and replica B moves it to SPAM,\r
  83      then you get two hard links to the same file, one in IMPORTANT and\r
  84      one in SPAM.]\r
  85 \r
  86    * If there's a conflict and two replicas have different tags on the\r
  87      same message, then the tags in notmuch's new.tags directive get\r
  88      logically ANDed, while all other tags get logically ORed.\r
  89 \r
  90 Granted, I've only been using this system for a week.  On the other\r
  91 hand, all I was doing was starting to test something I had written, yet\r
  92 it ended up being so much better than my old system that I couldn't go\r
  93 back and ended up using my system in production far earlier than\r
  94 anticipated...\r
  95 \r
  96 >> Making sure the write-operations update the time should be easy.  Most\r
  97 >> or all of the changes are probably funneled through\r
  98 >> _notmuch_message_sync.  Worst case, there are only 9 places in the\r
  99 >> source code that make use of a Xapian:WritableDatabase, so I'm pretty\r
 100 >> confident total changes wouldn't be much more than 50 lines of code.\r
 101 >\r
 102 > Maybe. Don't forget upgrading the database, updating the test suite, and\r
 103 > presumably some changes to the CLI so the new mtime can actually be\r
 104 > used. Not to be discouraging ;).\r
 105 \r
 106 The CLI is trivial.  We'll just add another search keyword ctime\r
 107 analogous to date.\r
 108 \r
 109 As far as updating the test suite, etc., it's almost certain that the\r
 110 core notmuch developers would be unsatisfied with whatever I've done,\r
 111 since the code base is very clean and has a very uniform style.  So when\r
 112 I say I'd want some "indication that such a change could be upstreamed,"\r
 113 I mean more specifically that someone would be willing to shepherd the\r
 114 process of getting the code into shape.\r
 115 \r
 116 > In the ensuing time, nothing better has developed for tag\r
 117 > synchronization (my pet use case) so maybe it's time to pursue this\r
 118 > again.\r
 119 \r
 120 I do have something pretty good for tag synchronization.  It requires a\r
 121 full database scan each time to detect changes, but I've heavily\r
 122 optimized it to be very fast by skipping over the notmuch library and\r
 123 directly scanning the underlying Xapian Btrees.  Currently my bottleneck\r
 124 is indexing messages (e.g., running notmuch new or calling\r
 125 notmuch_database_add_message), which are painfully slow on 32-bit\r
 126 machines.  (Unfortunately my mail server is a 32-bit machine.)\r
 127 \r
 128 To give you an idea, on a 32 bit machine, if I get a handful of new mail\r
 129 (e.g., 6 messages), running "notmuch new" takes 19 seconds, while\r
 130 scanning the database to check for renames and changed tags adds another\r
 131 1.4 seconds.  On a 64-bit machine, "notmuch new" might take 1 second,\r
 132 while scanning the database adds 350 msec.\r
 133 \r
 134 So full database scan's might not be the end of the world.  The biggest\r
 135 performance bottleneck at this point is notmuch's painful indexing\r
 136 performance.  It kills me that it takes 10 minutes to index 100,000 mail\r
 137 messages on a 16-core machine with 48 GiB of RAM.  But the library is\r
 138 non-reentrant and allocates thread IDs in such a way that it's hard to\r
 139 create parallel databases and later merge them.  Basically I can't\r
 140 figure out how to make productive use of more than one CPU core even\r
 141 when synchronizing across 1GB Ethernet!\r
 142 \r
 143 It's pretty beta, but my intention is to open-source my code, so glad\r
 144 for beta testers if you are interested in testing tag synchronization.\r
 145 \r
 146 > It would be good to have some preliminary idea about the time\r
 147 > and space costs of adding document mtimes.  I guess database bloat\r
 148 > should not be too bad, since it's only 64bits (?) per mail message.\r
 149 \r
 150 Plus a Btree to index it, so figure at least 24 bytes per message.\r
 151 Another issue is that values are always brought into memory with a\r
 152 document, so it will consume more RAM.  But yeah, I don't think it\r
 153 should be that bad.\r
 154 \r
 155 David\r