b9/4e19afedb5448ee1510dba367bb702d6531204

   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 BF484431FD0\r
   6         for <notmuch@notmuchmail.org>; Tue, 20 Dec 2011 12:25:58 -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.3\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_MED=-2.3] 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 OUnmXSGneKEz for <notmuch@notmuchmail.org>;\r
  16         Tue, 20 Dec 2011 12:25:58 -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 07485431FB6\r
  21         for <notmuch@notmuchmail.org>; Tue, 20 Dec 2011 12:25:57 -0800 (PST)\r
  22 Received: from convex-new.cs.unb.ca ([131.202.13.154])\r
  23         by tempo.its.unb.ca (8.13.8/8.13.8) with ESMTP id pBKKPrxa030568;\r
  24         Tue, 20 Dec 2011 16:25:53 -0400\r
  25 Received: from bremner by convex-new.cs.unb.ca with local (Exim 4.72)\r
  26         (envelope-from <bremner@unb.ca>)\r
  27         id 1Rd6G1-0001no-R1; Tue, 20 Dec 2011 16:25:53 -0400\r
  28 From: David Bremner <bremner@debian.org>\r
  29 To: Tom Prince <tom.prince@ualberta.net>, Austin Clements <amdragon@MIT.EDU>\r
  30 Subject: Re: More ideas about logging.\r
  31 In-Reply-To: <87r501k4ub.fsf@loki.hocat.ca>\r
  32 References: <87obv9i7y3.fsf@zancas.localnet> <20111216040722.GC12245@mit.edu>\r
  33         <87hb0xbug7.fsf@zancas.localnet> <87r501k4ub.fsf@loki.hocat.ca>\r
  34 User-Agent: Notmuch/0.10.2+93~g518d4ef (http://notmuchmail.org) Emacs/23.3.1\r
  35         (x86_64-pc-linux-gnu)\r
  36 Date: Tue, 20 Dec 2011 16:25:53 -0400\r
  37 Message-ID: <87k45r9ei6.fsf@convex-new.cs.unb.ca>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain; charset=us-ascii\r
  40 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\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: Tue, 20 Dec 2011 20:25:58 -0000\r
  54 \r
  55 On Sun, 18 Dec 2011 13:22:20 -0700, Tom Prince <tom.prince@ualberta.net> wrote:\r
  56 > On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner <bremner@debian.org> wrote:\r
  57 > > The more worrying part is disk usage; the tag tree for 200k messages\r
  58 > > uses 400k inodes, and 836M of apparent disk usage (according to du) the\r
  59 > > same tags in "sup" format take 11M.  Maybe this could be usefull if\r
  60 > > combined with some scheme to only dump tags not covered by maildir (for\r
  61 > > those using maildir flag synching already)\r
  62 > \r
  63 > Well, it would seem natural to re-use the nmbug logic here, and just use\r
  64 > a bare git repo for this. One would need a way to sync and merge the\r
  65 > tag-tree automatically anyway. I admit I haven't tried nmbug yet, but it\r
  66 > seems that nmbug, switched from sync just notmuch:: to syncing\r
  67 > everything but notmuch:: would be a sensible way to sync tags?\r
  68 \r
  69 I was mainly interested in if some guarantee of atomicity could be given\r
  70 in a simple way.  The git update-index approach doesn't really make\r
  71 those kind of guaranteees..  Probably this is tolerable for a human\r
  72 initiated "dump" process; not so much for other uses.  Furthermore much\r
  73 of the motivation for both mtimes and logging is to make incremental\r
  74 dumping possible in order to avoid the time to do of a full dump. This\r
  75 is experiment was also to see how feasible it was to insert some\r
  76 "mkdir+creat" in the notmuch-tag critical path.\r
  77 \r
  78 Since a few people have mentioned this, I should confess that\r
  79 there are (at least) 2 performance bugs lurking in nmbug that make it\r
  80 probably not yet suitable for large scale tag syncing.\r
  81 \r
  82 1) I did not get the merging working with only the index, so \r
  83    nmbug currently makes a temporary checkout to do the merge.\r
  84 \r
  85 2) transfering tags from the git repo to xapian is currently quite slow\r
  86    because it does one call to git tag for each tag, rather than\r
  87    constructing an input for "notmuch restore".  \r
  88 \r
  89 I _think_ both of these are fixable in principle.  Maybe somebody with\r
  90 better git internals knowledge than I would like to take a look at (1). \r
  91 (2) is just a SimpleMatterOfProgramming (TM). Patches, as they say, are\r
  92 welcome ;).\r
  93 \r
  94 d\r
  95 \r
  96 \r