Re: [PATCH 9/9] add has: query prefix to search for specific properties
[notmuch-archives.git] / 78 / 37a866b8dedf3f8ccadec0fc9defa164470694
1 Return-Path: <stewart@flamingspork.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 3A712431FBC\r
6         for <notmuch@notmuchmail.org>; Sun, 14 Feb 2010 16:29:24 -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: -0.721\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5\r
12         tests=[AWL=-0.722, BAYES_50=0.001] autolearn=ham\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 LdXSoGrFFfL8 for <notmuch@notmuchmail.org>;\r
16         Sun, 14 Feb 2010 16:29:23 -0800 (PST)\r
17 Received: from kaylee.flamingspork.com (kaylee.flamingspork.com\r
18         [74.207.245.61])\r
19         by olra.theworths.org (Postfix) with ESMTP id 2C829431FAE\r
20         for <notmuch@notmuchmail.org>; Sun, 14 Feb 2010 16:29:23 -0800 (PST)\r
21 Received: from willster (localhost [127.0.0.1])\r
22         by kaylee.flamingspork.com (Postfix) with ESMTPS id D2F746393\r
23         for <notmuch@notmuchmail.org>; Mon, 15 Feb 2010 00:26:23 +0000 (UTC)\r
24 Received: from flamingspork.com (localhost.localdomain [127.0.0.1])\r
25         by willster (Postfix) with ESMTPS id C7DD51023D8F\r
26         for <notmuch@notmuchmail.org>; Mon, 15 Feb 2010 11:29:18 +1100 (EST)\r
27 Date: Mon, 15 Feb 2010 11:29:14 +1100\r
28 From: Stewart Smith <stewart@flamingspork.com>\r
29 To: notmuch@notmuchmail.org\r
30 Message-ID: <20100215002914.GA22402@flamingspork.com>\r
31 MIME-Version: 1.0\r
32 Content-Type: text/plain; charset=us-ascii\r
33 Content-Disposition: inline\r
34 User-Agent: Mutt/1.5.20 (2009-06-14)\r
35 Subject: [notmuch] Mail in git\r
36 X-BeenThere: notmuch@notmuchmail.org\r
37 X-Mailman-Version: 2.1.13\r
38 Precedence: list\r
39 List-Id: "Use and development of the notmuch mail system."\r
40         <notmuch.notmuchmail.org>\r
41 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
42         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
43 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
44 List-Post: <mailto:notmuch@notmuchmail.org>\r
45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
46 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
47         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
48 X-List-Received-Date: Mon, 15 Feb 2010 00:29:24 -0000\r
49 \r
50 So... I sketched this out in my head at LCA... and it's taken a bit of\r
51 time to actually properly try it.\r
52 \r
53 The problem is:\r
54 A simple 'find ~/Maildir` takes 10 minutes, and if you write the\r
55 output to a file, it's 88MB+\r
56 \r
57 there's "only" about 900,000 entries there. But this means 900,000\r
58 files, which is a non-trivial amount. Some mail folders are quite\r
59 large too.\r
60 \r
61 Some of this problem could just be solved by using notmuch a bit\r
62 differently (folder per month for example).\r
63 \r
64 However... this is a one-way change and going back would be very\r
65 tricky.\r
66 \r
67 There's also the backup problem. Iterating through ~1million inodes\r
68 takes a *LONG* time. Restoring it takes even longer (think about\r
69 writing all that data to the file system journal).\r
70 \r
71 Historically, if i'm running a backup, I couldn't really use my\r
72 laptop, it'd be saturated with disk IO performing the file system\r
73 dump. It would also take many hours.\r
74 \r
75 Restoring from backup? about 8hrs.\r
76 \r
77 An observation is that mail never changes. It may be reclassified (and\r
78 that's what notmuch is for), but it never changes.\r
79 \r
80 We really just want a way to store and access many many many small\r
81 blobs of data that never change.\r
82 \r
83 It turns out git is pretty good at that. Underneath, we could just use\r
84 it as an object store (a simple git-hash-object and git-cat-file test\r
85 confirmed this to be pretty simple to do). even better is since a lot\r
86 of mail is fairly similar, to use delta compression between mail\r
87 messages to reduce the storage space. Git is pretty good at that too.\r
88 \r
89 A few giant git packs will be much quicker to backup and restore than\r
90 1million files.\r
91 \r
92 So... I wrote a script to test it....\r
93 \r
94 $ time perl /home/stewart/evenless.pl /home/stewart/Maildir/\r
95 \r
96 real    841m41.491s\r
97 user    491m3.200s\r
98 sys     261m58.080s\r
99 \r
100 Which goes from a 15GB Maildir to a 3.7GB git repo.\r
101 \r
102 The algorithm of evenless.pl is basically:\r
103 1 get next directory entry\r
104 2 if is directory, recurse into it\r
105 3 write item to git (git hash-object -w)\r
106 4 add item to tree object\r
107 5 if number of items written = 1000\r
108   5.1 make pack of last 1000 items\r
109 6 goto 1\r
110 \r
111 $ git count-objects -v\r
112 count: 479\r
113 size: 27680\r
114 in-pack: 873109\r
115 packs: 1084\r
116 size-pack: 3746219\r
117 prune-packable: 0\r
118 garbage: 0\r
119 \r
120 If i did a "git checkout", about 8 hours later i'd have a directory\r
121 tree exactly the same as my maildir.\r
122 \r
123 Why didn't I just git-add everything? I didn't exactly feel like\r
124 creating another giant copy of my mail (that also takes a long time).\r
125 \r
126 What about adding more mail to the archive?\r
127 \r
128 So the way I think is that you use a Maildir for day to day mail (e.g.\r
129 delivery) and every so often you run some magic command that takes old\r
130 mail out of the Maildir and stores it in the git repo.\r
131 \r
132 Next step?\r
133 \r
134 Make notmuch be able to read mail out of it and add it to an index\r
135 (oh, and some kind of verification and error checking about creating\r
136 the git repo).\r
137 -- \r
138 Stewart Smith\r