Re: [Gaudenz Steinlin] Bug#810784: should match email adress case insensitive when...
[notmuch-archives.git] / cc / 4eb726b18604a45a63b033d60f78682aaebcca
1 Return-Path: <eirik@eirikba.org>\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 7050C431FAF\r
6         for <notmuch@notmuchmail.org>; Thu, 29 Nov 2012 11:34: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: -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 gweATqeNm2zi for <notmuch@notmuchmail.org>;\r
16         Thu, 29 Nov 2012 11:34:54 -0800 (PST)\r
17 Received: from atmail.labs2.com (atmail.labs2.com [93.182.166.49])\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 5A570431FAE\r
21         for <notmuch@notmuchmail.org>; Thu, 29 Nov 2012 11:34:54 -0800 (PST)\r
22 Received: from [178.74.1.248] (helo=star.eba)\r
23         by atmail.labs2.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77)\r
24         (envelope-from <eirik@eirikba.org>) id 1Te9sh-0006gE-Hf\r
25         for notmuch@notmuchmail.org; Thu, 29 Nov 2012 20:34:43 +0100\r
26 Received: from eirik by star.eba with local (Exim 4.80)\r
27         (envelope-from <eirik@eirikba.org>) id 1Te9so-0002WP-70\r
28         for notmuch@notmuchmail.org; Thu, 29 Nov 2012 20:34:50 +0100\r
29 From: Eirik Byrkjeflot Anonsen <eirik@eirikba.org>\r
30 To: "notmuch mailing list" <notmuch@notmuchmail.org>\r
31 Subject: Re: On disk tag storage format\r
32 References: <874nk8v9zw.fsf@zancas.localnet>\r
33 Date: Thu, 29 Nov 2012 20:34:50 +0100\r
34 In-Reply-To: <874nk8v9zw.fsf@zancas.localnet> (David Bremner's message of\r
35         "Thu, 29 Nov 2012 09:01:23 -0400")\r
36 Message-ID: <874nk8td7p.fsf@star.eba>\r
37 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)\r
38 MIME-Version: 1.0\r
39 Content-Type: text/plain; charset=us-ascii\r
40 X-ACL-Warn: Authenticated as:  Sent as: eirik@eirikba.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: Thu, 29 Nov 2012 19:34:58 -0000\r
54 \r
55 David Bremner <david@tethera.net> writes:\r
56 \r
57 > Austin outlined on IRC a way of representing tags on disk as hardlinks\r
58 > to messages. In order to make the discussion more concrete, I wrote a\r
59 > prototype in python to dump the notmuch database to this format. On my\r
60 > 250k messages, this creates 40k new hardlinks, and uses about 5M of\r
61 > diskspace. The dump process takes about 20s on\r
62 > my core i7 machine.  With symbolic links, the same database takes about\r
63 > 150M of disk space; this isn't great but it isn't unbearable either.\r
64 \r
65 And eating 40k inodes, I suppose.  Which may matter to some systems.\r
66 (Hardlinks do not use extra inodes, as they are just directory entries\r
67 pointing to already existing inodes).\r
68 \r
69 Of course, the space usage also depends on the file system, as e.g. ext2\r
70 would use 1 complete block (typically 4kiB) to store the file name\r
71 pointed to per symlink.  ReiserFS would probably use 5M for the\r
72 directory entries and another 5M for the symlink data (wild guess).\r
73 \r
74 eirik\r