6a/dad367419b97d44345cfcbee716dec0632f9c9

   1 Return-Path: <bremner@unb.ca>\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 D20F4429E25\r
   6         for <notmuch@notmuchmail.org>; Thu, 15 Dec 2011 18:09:22 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.29\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 W47AL3x4Dd29 for <notmuch@notmuchmail.org>;\r
  16         Thu, 15 Dec 2011 18:09:21 -0800 (PST)\r
  17 Received: from tempo.its.unb.ca (tempo.its.unb.ca [131.202.1.21])\r
  18         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id BE9D1431FD0\r
  21         for <notmuch@notmuchmail.org>; Thu, 15 Dec 2011 18:09:21 -0800 (PST)\r
  22 Received: from zancas.localnet\r
  23         (fctnnbsc36w-156034079193.pppoe-dynamic.High-Speed.nb.bellaliant.net\r
  24         [156.34.79.193]) (authenticated bits=0)\r
  25         by tempo.its.unb.ca (8.13.8/8.13.8) with ESMTP id pBG29HC7007905\r
  26         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);\r
  27         Thu, 15 Dec 2011 22:09:18 -0400\r
  28 Received: from bremner by zancas.localnet with local (Exim 4.77)\r
  29         (envelope-from <bremner@unb.ca>)\r
  30         id 1RbNEb-0005Jj-11; Thu, 15 Dec 2011 22:09:17 -0400\r
  31 From: David Bremner <bremner@debian.org>\r
  32 To: "Notmuch Mail" <notmuch@notmuchmail.org>\r
  33 Subject: More ideas about logging.\r
  34 User-Agent: Notmuch/0.10.2+100~g7a23455 (http://notmuchmail.org) Emacs/23.3.1\r
  35         (x86_64-pc-linux-gnu)\r
  36 Date: Thu, 15 Dec 2011 22:09:08 -0400\r
  37 Message-ID: <87obv9i7y3.fsf@zancas.localnet>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: multipart/signed; boundary="=-=-=";\r
  40         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  41 Cc: Olly Betts <olly@survex.com>\r
  42 X-BeenThere: notmuch@notmuchmail.org\r
  43 X-Mailman-Version: 2.1.13\r
  44 Precedence: list\r
  45 List-Id: "Use and development of the notmuch mail system."\r
  46         <notmuch.notmuchmail.org>\r
  47 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  49 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  50 List-Post: <mailto:notmuch@notmuchmail.org>\r
  51 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  52 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  54 X-List-Received-Date: Fri, 16 Dec 2011 02:09:23 -0000\r
  55 \r
  56 --=-=-=\r
  57 Content-Transfer-Encoding: quoted-printable\r
  58 \r
  59 \r
  60 Various discussions (mostly on IRC) from my jlog proposal, and a from\r
  61 Thomas's mtime\r
  62 (id:"1323796305-28789-1-git-send-email-schnouki@schnouki.net") proposal\r
  63 got me thinking.  So let me know what you think about the following.\r
  64 \r
  65 The goal here is to log tag adds and deletes (including those implicit\r
  66 in message deletion) to facilitate tag synchonization.\r
  67 \r
  68 If we use Xapian to store transaction numbers (much as the\r
  69 last_thread_id is stored now), then we don't need an external logging\r
  70 library. We can rely on the xapian to keep other clients from writing\r
  71 \r
  72 Assume we have routines read_metadata and write_metadata that read and\r
  73 write to the xapian database metadata (in real life, I think we might\r
  74 need to decide in advance exactly what will be written there).\r
  75 \r
  76 when we create a database\r
  77 \r
  78 write_metadata('log_write',0)\r
  79 write_metadata('log_read',0) // more about this later\r
  80 \r
  81 To carry out database operation X with logging, we do the following\r
  82 \r
  83 begin_atomic\r
  84 \r
  85     txn=3Dread_metadata('last_written')\r
  86 \r
  87     X\r
  88 \r
  89     // begin dangerzone\r
  90     fprintf(logfile,"%d %s",num+1,stuff) // or whatever.\r
  91 \r
  92     write_metadata('last_written', num+1)\r
  93 \r
  94 end_atomic\r
  95 //end dangerzone\r
  96 \r
  97 If I understand correctly, then the only way the database and the log\r
  98 can get out of sync is if this is interrupted in the "dangerzone"\r
  99 between the start of the log write and the end of the xapian atomic\r
 100 transaction. But then since we can consider the database authoritative\r
 101 (since our goal is synchonization rather than recovery), we can discard\r
 102 those portions of the log. We have to be a bit careful to discard\r
 103 incomplete log items at the end of the log (maybe a checksum?).\r
 104 \r
 105 So how do we discard? Two places. At the opening of the database for\r
 106 writing, we truncate the log file (if we are very lazy, we can use seek\r
 107 offsets as transaction indicies to facilitate this).=20\r
 108 \r
 109 In order to guarantee that log item is output exactly once, it seems\r
 110 like we need another counter (or maybe I'm overthinking this)\r
 111 \r
 112      read_ptr =3D read_metadata('last_read')\r
 113 \r
 114      write_ptr =3D read_metadata('last_write')\r
 115 =20=20=20=20=20\r
 116      while (read_ptr < write_ptr) {\r
 117          begin_atomic\r
 118             s =3D read(read_ptr)\r
 119             do_stuff(s)\r
 120             read_ptr++\r
 121             write_metadata('log_read', read_ptr);\r
 122          end_atomic\r
 123      }\r
 124 \r
 125      write_metadata('log_write',0) // The log file will be truncated on\r
 126                                    // on db open\r
 127      write_metadata('log_read',0)=20\r
 128 \r
 129 I think we can double check if write_ptr <=3D read_ptr on next db open,\r
 130 and truncate then if needed.\r
 131 \r
 132 I think we need to assume that do_stuff is atomic here; I'm not sure how\r
 133 reasonable or unreasonable that is in practice.\r
 134 \r
 135 I also don't know about the performance implications of reading and\r
 136 writing like maniac from the xapian metadata. Of course if this whole\r
 137 scheme is fatally flawed, no need to worry about performance.\r
 138 \r
 139 I don't think the actual amount of code involved would be too bad. Of\r
 140 course, I thought was going to be a short message too.\r
 141 \r
 142 d\r
 143 \r
 144 \r
 145 --=-=-=\r
 146 Content-Type: application/pgp-signature\r
 147 \r
 148 -----BEGIN PGP SIGNATURE-----\r
 149 Version: GnuPG v1.4.11 (GNU/Linux)\r
 150 \r
 151 iJwEAQECAAYFAk7qqEUACgkQTiiN/0Um85mVgAQAop6yw5qniOmbqUn5XkmH0eTx\r
 152 YdDwkopNIyHPfRzZP4ZJIkYyoTnvfK94fd8rhsM8CWSFfORhwRLRWbjLZb5iyTHV\r
 153 Nk+8gAHiDCueoJ+lI01uxrrxWQmzLYz1qwK6e2zYtqp9rU2INbn8lOgaBDEV52Fq\r
 154 y2oJBmVaUI8p9eVQSaM=\r
 155 =cSaO\r
 156 -----END PGP SIGNATURE-----\r
 157 --=-=-=--\r