From: Tomi Ollila <tomi.ollila@iki.fi>
To: Eirik Byrkjeflot Anonsen <eirik@eirikba.org>,
	notmuch mailing list <notmuch@notmuchmail.org>
Subject: Re: On disk tag storage format
In-Reply-To: <874nk8td7p.fsf@star.eba>
References: <874nk8v9zw.fsf@zancas.localnet> <874nk8td7p.fsf@star.eba>
User-Agent: Notmuch/0.14+116~g29fcdb5 (http://notmuchmail.org) Emacs/24.2.1
	(x86_64-unknown-linux-gnu)
Date: Fri, 30 Nov 2012 09:31:31 +0200
Message-ID: <m2d2yvlf70.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Thu, Nov 29 2012, Eirik Byrkjeflot Anonsen <eirik@eirikba.org> wrote:

> David Bremner <david@tethera.net> writes:
>
>> Austin outlined on IRC a way of representing tags on disk as hardlinks
>> to messages. In order to make the discussion more concrete, I wrote a
>> prototype in python to dump the notmuch database to this format. On my
>> 250k messages, this creates 40k new hardlinks, and uses about 5M of
>> diskspace. The dump process takes about 20s on
>> my core i7 machine.  With symbolic links, the same database takes about
>> 150M of disk space; this isn't great but it isn't unbearable either.
>
> And eating 40k inodes, I suppose.  Which may matter to some systems.
> (Hardlinks do not use extra inodes, as they are just directory entries
> pointing to already existing inodes).
>
> Of course, the space usage also depends on the file system, as e.g. ext2
> would use 1 complete block (typically 4kiB) to store the file name
> pointed to per symlink.  ReiserFS would probably use 5M for the
> directory entries and another 5M for the symlink data (wild guess).

IIRC in mid 1990's (some) frisbee fs stored many symbolic links to one
inode and, at the same time, stored multiple link names to same fs block
... note that IIRC :D

> eirik

Tomi

> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch