5b/a499b118cb49d4c0a766c9adc288ecae36e0e3

   1 Return-Path: <ciprian.craciun@gmail.com>\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 23AE9431FC2\r
   6         for <notmuch@notmuchmail.org>; Tue, 14 Aug 2012 09:38:26 -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.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 JbwhBHq76UMo for <notmuch@notmuchmail.org>;\r
  17         Tue, 14 Aug 2012 09:38:25 -0700 (PDT)\r
  18 Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com\r
  19  [74.125.82.45])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  20  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  21  2310A431FAE    for <notmuch@notmuchmail.org>; Tue, 14 Aug 2012 09:38:25 -0700\r
  22  (PDT)\r
  23 Received: by wgbdq12 with SMTP id dq12so498176wgb.2\r
  24         for <notmuch@notmuchmail.org>; Tue, 14 Aug 2012 09:38:22 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
  26         h=mime-version:in-reply-to:references:date:message-id:subject:from:to\r
  27         :content-type; bh=pDHM2SnMCIian2BbvOSvTGSNB0/0/BQMahDhcEkTjQo=;\r
  28         b=olQ4a6P8fw0+XRUM73Xr8heOeUKYVU/5mMVbr8sWJzJqjTyfDiymmMAr0dFw6u++fS\r
  29         422o/gREtlppqABZXWTsceTd2hEhTjHSNTjJbZCNX3ZneBnn2CiSbGgn45S9UXOM9rNj\r
  30         mW17kpgQDqkO5TpJiVDHXhWk/7+WVNgC+I/Go/lS9fESXG5LiA3mehY7ZpqMrdbDHYSr\r
  31         +5dfnm00NhZThdl8ysk/9D8P41DQswoOAfU8XMcCMpX+gsoIaWW2t9ewy+1FBKhII0al\r
  32         NSReFTvXAxf8jaU+rUNVgGA+8i3tNDAdGTy7gMOcpvt1kqhd9XMbVblkPyXDpgSBk11W\r
  33         UDiQ==\r
  34 MIME-Version: 1.0\r
  35 Received: by 10.180.94.164 with SMTP id dd4mr29323720wib.1.1344962302574; Tue,\r
  36         14 Aug 2012 09:38:22 -0700 (PDT)\r
  37 Received: by 10.180.104.196 with HTTP; Tue, 14 Aug 2012 09:38:22 -0700 (PDT)\r
  38 In-Reply-To: <20120814160442.GO28321@pub.cz.oracle.com>\r
  39 References:\r
  40  <CA+Tk8fwq2thNeKHgfG-EX0hgR7uyqrSce0ZMOhEJBsz1RVtRqg@mail.gmail.com>\r
  41         <20120811094635.GY28321@pub.cz.oracle.com>      <874no613ms.fsf@flamingspork.com>\r
  42         <20120814160442.GO28321@pub.cz.oracle.com>\r
  43 Date: Tue, 14 Aug 2012 19:38:22 +0300\r
  44 Message-ID:\r
  45  <CA+Tk8fwVwWewTS-AVaaapQpLNU6a698acp-_ZmnktJ5ynRrx1A@mail.gmail.com>\r
  46 Subject: Re: Alternative (raw) message store (i.e. instead of maildir)\r
  47 From: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>\r
  48 To: Stewart Smith <stewart@flamingspork.com>, notmuch@notmuchmail.org\r
  49 Content-Type: text/plain; charset=UTF-8\r
  50 X-BeenThere: notmuch@notmuchmail.org\r
  51 X-Mailman-Version: 2.1.13\r
  52 Precedence: list\r
  53 List-Id: "Use and development of the notmuch mail system."\r
  54         <notmuch.notmuchmail.org>\r
  55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  58 List-Post: <mailto:notmuch@notmuchmail.org>\r
  59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  62 X-List-Received-Date: Tue, 14 Aug 2012 16:38:26 -0000\r
  63 \r
  64 On Tue, Aug 14, 2012 at 7:04 PM, Vladimir Marek\r
  65 <Vladimir.Marek@oracle.com> wrote:\r
  66 >> >  - fuse zip stores all changes in memory until unmounted\r
  67 >> >  - fuse zip (and libzip for that matter) creates new temporary file when\r
  68 >> >    updating archive, which takes considerable time when the archive is\r
  69 >> >    very big.\r
  70 >>\r
  71 >> This isn't much of a hastle if you have maildir per time period and\r
  72 >> archive off. Maybe if you sync flags it may be...\r
  73 >\r
  74 > That might be interesting solution, maildir per time period.\r
  75 \r
  76 \r
  77     Although using a zip file through FUSE as a maildir store is not\r
  78 much better in my opinion.\r
  79 \r
  80     This is because it still doesn't solve the syscall overhead. For\r
  81 example just going through the list of files to find those that\r
  82 changed requires the following syscalls:\r
  83     * reading the next directory entry (which is amortized as it reads\r
  84 them in a batch, but the batch size is limited, should we say 1\r
  85 syscall per 10 files?);\r
  86     * stat-ing the file;\r
  87 \r
  88     Now by adding FUSE we add an extra context switch for each syscall...\r
  89 \r
  90     Although this issue would be problematic only for reindexing, but still...\r
  91 \r
  92 \r
  93 > But still\r
  94 > fuse zip caches all the data until unmounted. So even with just reading\r
  95 > it keeps growing (I hope I'm not accusing fuse zip here, but this is my\r
  96 > understanding form the code). This could be simply alleviated by having\r
  97 > it periodically unmounted and mounted again (perhaps from cron).\r
  98 \r
  99     I think there is an option for FUSE mount to specify if the data\r
 100 should be cached by the kernel or not, as such this shouldn't be a\r
 101 problem for FUSE itself, except if the Zip FUSE handler does some\r
 102 extra caching.)\r
 103 \r
 104 \r
 105 >> > Of course this solution would have some disadvantages too, but for me\r
 106 >> > the advantages would win. At the moment I'm not sure if I want to\r
 107 >> > continue working on that. Maybe if there would be more interested guys\r
 108 >>\r
 109 >> I'm *really* tempted to investigate making this work for archived\r
 110 >> mail. Of course, the list of mounted file systems could get insane\r
 111 >> depending on granularity I guess...\r
 112 >\r
 113 > Well, if your granularity will be one archive per year of mail, it\r
 114 > should not be that bad ...\r
 115 \r
 116 \r
 117     On the other hand I strongly sustain having a more optimized\r
 118 backend for emails, especially for such cases. For example a\r
 119 BerkeleyDB would perfectly fit such a use case, especially if we store\r
 120 the body and the headers in separate databases.\r
 121 \r
 122     Just a small experiment, below are the R `summary(emails)` of the\r
 123 sizes of my 700k emails:\r
 124 ~~~~\r
 125     Min.  1st Qu.   Median     Mean  3rd Qu.     Max.\r
 126        8     4364     5374    11510     7042 31090000\r
 127 ~~~~\r
 128 \r
 129     As seen 75% of the emails are below 7k, and this without any compression...\r
 130 \r
 131     Moreover we could organize the keys so that in a B-Tree structure\r
 132 the emails in the same thread are closer together...\r
 133 \r
 134     Ciprian.\r