From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <20b12c0579ef5660c3e08fe8f93fbd7f@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue,  9 Jun 2009 14:59:52 -0400
To: nemo@lsub.org, 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Different representations of the same file/resource in
	a synthetic FS
Topicbox-Message-UUID: 07ff3252-ead5-11e9-9d60-3106f5b1d025

On Tue Jun  9 14:15:29 EDT 2009, nemo@lsub.org wrote:
> With mail2fs I leave messages alone and use all kinds of mail lists
> that contain just relative paths to actual messages. Perhaps nupas
> could do the same.
>

i think that essential strategy is a winner.  upas would use
.idx files.

so the general plan would be to never delete messages.
they're in the dump anyway.  just delete them from
the index.

so that seems simple, why isn't that done already?

first, i should point out that there are some complicating
assumptions i have.  our heavy users are receiving
about 1000 messages a day after spam filtering.  it would
be pretty easy to accumulate a million messages.  also,
it's important for imap support to be able to scan several
hundred mailboxes in short order.

hopefully that's enough context to understand the two
basic problems i see:
1.  the mdir format is limited by the underlying fs
in the number of messages that can be efficiently
stored.  (my previous tests with ken's fs on a pIII
machine showed that 100k was a lower upper bound.)
a million-message index would be ~600mb on-disk.

2.  upas/fs needs memory proportinal to the number
of messages in the mailbox.  and clients need to read
directories that are sized in proportion to the number
of messages.

#1 seems straightforward to fix.  #2 seems more
fundamental.

- erik