Re: Maildir backend

[Matt Armstrong <matt@lickey.com>]

prj@po.cwru.edu (Paul Jarc) writes:

> Jérôme Marant <jerome.marant@fr.thalesgroup.com> wrote:
>>   I'm trying to understand why it is slow on startup.
>
> I haven't profiled it, but I'm pretty sure it's because it read all
> the NOV information at startup.  It uses this information to build a
> fast mapping among filenames, article numbers, and Message-IDs,
> which speeds things up later when we want to find a message by
> Message-ID, for example.
>
> Currently article numbers are only stored in memory, so they change
> between Gnus sessions.  This messes with the cache, the agent, and
> 'seen marks, so I'm going to change it when I have some time.  As
> part of that revision, I think I can get rid of the slow startup.
> E.g., I might create a new subdirectory in .nnmaildir/ which
> contains files with names like this:
> 154:<20020313115128.A9018@fr.thalesgroup.com>:1016016979.15575.multivac.cwru.edu
> I.e., article-number:message-id:unique-part-of-filename-in-cur.
> Then when we're looking for an article, we can just scan this
> directory, looking for whichever identification field we happen to
> have.  Since all the information here is contained in the filename,
> the files can be empty, and can even be hard links to a single file
> to avoid consuming lots of inodes.

Have you considered placing NOV data in a single .overview file like
nnml?  What is the advantage to keeping nov data in separate files?
My guess is that this will be faster for the common case: when folks
are running on a traditional unix file system.  But it probably boils
down to a philosophical argument.  Neither nnml nor nnmailder are
probably the best tool for storing HUGE mail folders.

-- 
matt