b1/7f97089259c2d66d78a5cffaab6bc4050dfd80

   1 Return-Path: <amdragon@mit.edu>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 09C44431FBD\r
   6         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 13:59:37 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id SXgPjVp1H138 for <notmuch@notmuchmail.org>;\r
  16         Wed, 23 Apr 2014 13:59:29 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu\r
  18         [18.7.68.34])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 4AFA9431FAE\r
  20         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 13:59:29 -0700 (PDT)\r
  21 X-AuditID: 12074422-f79186d00000135a-cf-535829b022e6\r
  22 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  23         (using TLS with cipher AES256-SHA (256/256 bits))\r
  24         (Client did not present a certificate)\r
  25         by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
  26         id 39.09.04954.0B928535; Wed, 23 Apr 2014 16:59:28 -0400 (EDT)\r
  27 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
  28         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s3NKxQ0j020016; \r
  29         Wed, 23 Apr 2014 16:59:27 -0400\r
  30 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  31         (authenticated bits=0)\r
  32         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  33         by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s3NKxMNb008365\r
  34         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
  35         Wed, 23 Apr 2014 16:59:24 -0400\r
  36 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
  37         (envelope-from <amdragon@mit.edu>)\r
  38         id 1Wd4GI-0004jG-1m; Wed, 23 Apr 2014 16:59:22 -0400\r
  39 Date: Wed, 23 Apr 2014 16:59:20 -0400\r
  40 From: Austin Clements <amdragon@MIT.EDU>\r
  41 To: David Mazieres expires 2014-07-22 PDT\r
  42         <mazieres-eqbxrjbqrn7vs5xdx45e9hkucs@temporary-address.scs.stanford.edu>\r
  43 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
  44         changed on disk\r
  45 Message-ID: <20140423205920.GM25817@mit.edu>\r
  46 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  47         <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
  48         <87wqexnqvb.fsf@ta.scs.stanford.edu> <1397163239-sup-5101@qwerzila>\r
  49         <87d2g9ja0h.fsf@maritornes.cs.unb.ca> <1398237865-sup-624@qwerzila>\r
  50         <87ioq0l8th.fsf@ta.scs.stanford.edu>\r
  51 MIME-Version: 1.0\r
  52 Content-Type: text/plain; charset=us-ascii\r
  53 Content-Disposition: inline\r
  54 In-Reply-To: <87ioq0l8th.fsf@ta.scs.stanford.edu>\r
  55 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  56 X-Brightmail-Tracker:\r
  57  H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixG6nortBMyLY4OFaFYsbrd2MFk2fL7Fa\r
  58         HJ/+hc3i+s2ZzA4sHj/+NbN5PFt1i9nj0t9tTB5bDr1nDmCJ4rJJSc3JLEst0rdL4Mo4OMWq\r
  59         oEe2YsbtE6wNjNvFuxg5OSQETCSaFs1kg7DFJC7cWw9kc3EICcxmklh7dw8jhLORUWLhyVfs\r
  60         EM5pJol36/exQDhLGCV+Hf7KAtLPIqAq8XPZT7BZbAIaEtv2L2cEsUUEiiSur/wPFmcGsk/v\r
  61         3A1WLywQJzHt8g4mEJtXQEfiQvdEZhBbSOAAk8TOP3wQcUGJkzOfsED0aknc+PcSqJ4DyJaW\r
  62         WP6PAyTMKWAosafrPTuILSqgIjHl5Da2CYxCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk\r
  63         3eLkxLy81CJdU73czBK91JTSTYzg8HdR2sH486DSIUYBDkYlHt4DF8KDhVgTy4orcw8xSnIw\r
  64         KYnyqilGBAvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4c3SAMrxpiRWVqUW5cOkpDlYlMR531pb\r
  65         BQsJpCeWpGanphakFsFkZTg4lCR4z4E0ChalpqdWpGXmlCCkmTg4QYbzAA2fBja8uCAxtzgz\r
  66         HSJ/ilFRSpx3mzpQQgAkkVGaB9cLS0+vGMWBXhHmLQdp5wGmNrjuV0CDmYAGF0wIBxlckoiQ\r
  67         kmpgnF/YalHz60r/hKxd/IFSQdeuPDnm+K98SrmW9aPN0lGuSqyp1X4ZR/lOGD7dOeFfwcvV\r
  68         B6/qhuct3uK9TenwhMjFBTPbr0v8qV/t1ZbWdFpY/zTbvbevH3FLvWf+LLlc7vvUf+vL7S/M\r
  69         W3Xhcr7blGX3D9UrVyXov3+jaiW1/na0B+ORzoWs3UosxRmJhlrMRcWJAJ0nCSsqAwAA\r
  70 Cc: notmuch <notmuch@notmuchmail.org>\r
  71 X-BeenThere: notmuch@notmuchmail.org\r
  72 X-Mailman-Version: 2.1.13\r
  73 Precedence: list\r
  74 List-Id: "Use and development of the notmuch mail system."\r
  75         <notmuch.notmuchmail.org>\r
  76 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  78 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  79 List-Post: <mailto:notmuch@notmuchmail.org>\r
  80 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  81 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  82         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  83 X-List-Received-Date: Wed, 23 Apr 2014 20:59:37 -0000\r
  84 \r
  85 Hi Dave!\r
  86 \r
  87 Quoth David Mazieres on Apr 23 at  2:00 am:\r
  88 > Gaute Hope <eg@gaute.vetsj.com> writes:\r
  89 > \r
  90 > > A db-tick or a _good_ ctime solution can as far as I can see solve both\r
  91 > > David M's (correct me if I am wrong) and my purposes, as well as\r
  92 > > probably have more use cases in the future. It would even be an\r
  93 > > interesting direct search: show me everything that changed lately,\r
  94 > > sorted.\r
  95 > \r
  96 > I could live with a db-tick scheme.  I would prefer a ctime scheme,\r
  97 > since then I can answer questions such as "what has changed in the last\r
  98 > five minutes"?  I mean all kinds of other stuff starts to break if your\r
  99 > clock goes backwards on a mail server machine, not the least of which is\r
 100 > that incremental backups will fail silently, so you risk losing your\r
 101 > mail.\r
 102 > \r
 103 > A middle ground might be to use the maximum of two values: 1) the\r
 104 > time-of-day at which notmuch started executing, and 2) the highest ctime\r
 105 > in the database plus 100 microseconds (leaving plenty of slop to store\r
 106 > timestamps as IEEE doubles with 52 significant bits).  Since the values\r
 107 > will be Btree-indexed, computing the max plus one will be cheap.\r
 108 \r
 109 This makes me curious if you've considered how to fit this in to\r
 110 Xapian.  The Xapian query syntax supports range queries over document\r
 111 "values", but within the Xapian B-tree, values are stored in docid\r
 112 order, not value order, so Xapian's range query operator is actually a\r
 113 full scan in implementation.  I assume it does this so it doesn't have\r
 114 to store both forward and inverse indexes of values.  (I spent some\r
 115 time figuring out the layout of the Xapian database and have fairly\r
 116 detailed notes if anyone's curious.)\r
 117 \r
 118 This is still reasonably fast in practice because it's a sequential\r
 119 scan and only requires a few bytes per message, but it's probably not\r
 120 what you'd expect.  That said, Xapian does track per-value statistics\r
 121 that would suffice for the particular problem of monotonic time stamps\r
 122 (e.g., Database::get_value_upper_bound).\r
 123 \r
 124 In principle it would be possible to use user metadata or even\r
 125 document terms to support true B-tree range scans by ctime order, but\r
 126 I don't think it's possible to express queries over this using\r
 127 Xapian's query parser.  I've written about 90% of a (new) custom query\r
 128 parser for Notmuch that would enable this, but little things like my\r
 129 looming thesis deadline have interfered with me finishing it.\r
 130 \r
 131 > Incidentally, if you are really this paranoid about time stamps, it\r
 132 > should bother you that notmuch's directory timestamps only have one\r
 133 > second granularity.  It's not that hard to get a new message delivered\r
 134 > in the same second that notmuch new finished running.  In my\r
 135 > synchronizer, I convert st_mtim (a struct timespec) into a double and\r
 136 > keep that plus size in the database to decide if I need to re-hash\r
 137 > files.  But for directories, I'm stuck with NOTMUCH_VALUE_TIMESTAMP,\r
 138 > which are quantized to the second.  (Ironically, I think\r
 139 > Xapian::sortable_serialize converts time_ts to doubles anyway, so\r
 140 > avoiding st_mtim is not really helping performance.)\r
 141 \r
 142 This is historical (and, I agree, unfortunate).  But nobody's\r
 143 complained, so it hasn't been worth changing the libnotmuch interface\r
 144 to support sub-second directory mtimes.  However, notmuch new does\r
 145 correctly handle deliveries in the same second it runs.  If the\r
 146 wall-clock time when it starts is the same as the on-disk directory\r
 147 mtime, it skips updating the in-database directory mtime at the end.\r
 148 Hence, on the next run, it will still consider the directory\r
 149 out-of-date.  It's a bit of a hack, but it's a hack that would be\r
 150 necessary for supporting older file systems even if we did support\r
 151 sub-second timestamps.\r