Re: Questions on nnmaildir

[prj@po.cwru.edu (Paul Jarc)]

Something seems to be up with my subscription; I haven't received any
ding messages since Friday, when there were DNS changes for
multivac.cwru.edu.

Thomas Neumann <blacky_tn@gmx.de> wrote:
> It seems that nnmaildir is quite an inode-hogger.

The files in */.nnmaildir/marks/*/ are hard links.  By default, they
use one inode per group, but if you create */.nnmaildir/markfile
yourself as a hard link, you can use just one inode total.

The files in */.nnmaildir/num/ are hard links.  One extra inode per
group.

The files in */.nnmaildir/nov/ are separate inodes; nnmaildir uses two
inodes per message, where nnml and nnmh use one.

> Wouldn't it make more sense to handle the marks in a fashion close to
> courier? [appending them to the filename]

The current method makes it easier to manipulate marks from outside
Gnus, and for nnmaildir to pick up changes on the fly (whether made
from a shell, or from a concurrent Gnus).  Gnus also has more marks
than the standard maildir format.

You add a hook function to sync nnmaildir's marks with Courier's with
a script: when scanning for new messages, update nnmaildir's marks;
when exiting a group, update Courier's.

> Is it really that much faster for nnmaildir to pick a specific nov-file
> and grab its contents then to search through a single file containing
> all novs and look for a match?

The task here is to fetch some persistently-stored information indexed
by a string (the unique part of the message's filename).  That is
precisely what the filesystem is meant for.  Historically, many
filesystems didn't do a great job of it, and if you're stuck with one
of those, maybe nnmaildir isn't for you.  But if you're not, ReiserFS
or another modern filesystem may be just what you need.


paul