Bakul Shah <ba...@bitblocks.com> wrote:
|On Mon, 13 Oct 2014 12:15:31 EDT erik quanstrom <quans...@quanstro.net> \
|wrote:
|> On Sun Oct 12 14:37:47 EDT 2014, st...@quintile.net wrote:
|>> I am fairly sure the problem is to do with RAM size rather than the ras=
|> pberry pi per-se.
|>> 4000 messages takes up a lot of space - and upas stores messages in RAM=
|> .
|>
|> it's a little worse than this, actually.
|> the solutions to this are straightforward
|> (1) store one message per file,
|
|This is what MH (an old mail client) does by default.
|
|> (2) cache important data in an index to avoid opening all files,
|
|This is what dovecot (an imap/pop3 server) does.
Jamie Zawinski implemented that for Netscape 2.0/3.0 [1] but still
went for MBOX format. But of course that wasn't designed for
Plan9 and permanent backup storage. The page says
Right now I'm looking at a folder in 3.0. It has 15,466 messages
in it. Selecting this folder takes less than a second (it's hard
to eyeball it, but I'd say it takes about 1/2 to 3/4 second from
when I click to when I see the message summary on the screen).
The BSD mbox file is 57.2MB (1.2 million lines) and the summary
file is 1.3MB (2% of the size of the folder.)
This is on a P266 with a local IDE disk (Linux.)
[1] <http://www.jwz.org/doc/mailsum.html>
--steffen
--- Begin Message ---
On Mon, 13 Oct 2014 12:15:31 EDT erik quanstrom <quans...@quanstro.net> wrote:
> On Sun Oct 12 14:37:47 EDT 2014, st...@quintile.net wrote:
> > I am fairly sure the problem is to do with RAM size rather than the ras=
> pberry pi per-se.
> > 4000 messages takes up a lot of space - and upas stores messages in RAM=
> .
>
> it's a little worse than this, actually.
>
> since upas stores messages in mbox format, the whole file needs to be rea=
> d or written on
> update. certainly one could optimize the read bit, but that would be dif=
> ficult this means
> that the the whole mbox gets written to the dump every day, and you need =
> about 2x the
> mailbox size ram for each upas/fs that is run. this does not work out we=
> ll for large mm
> messages, or small ram boxes like the pi.
>
> the solutions to this are straightforward
> (1) store one message per file,
This is what MH (an old mail client) does by default.
> (2) cache important data in an index to avoid opening all files,
This is what dovecot (an imap/pop3 server) does.
One other thing such mailservers do is to usually only
*append* to an mbox file. Deleted messages are marked as such
but their space is not reclaimed until you force a rebuild of
the mbox file and its index.
Pure imap clients typically only read last N messages from a
given mailbox. More may be loaded as you scroll back.
--- End Message ---
