[9fans] Anyone working on new upas/fs?

[9fans] Anyone working on new upas/fs?

[Brantley Coile]

I've got some heartburn about upas/fs.  Seems our
user base is growing larger than main memories of our
imap servers.  Anyone have any ideas to keep systems from
running out of memory?  Anyone using something that
virtual memory to keep the mail boxes?

Re: [9fans] Anyone working on new upas/fs?

[Francisco J Ballesteros]

I unpack mail as it arrives, using mail2fs (I think it's at the planb
contrib in sources).
Then it's just a matter of using the actual file server to read mail.

To send mail, I have a couple of scripts (not worth posting) that
spool mail-files
created at a directory used for that.

On 2/9/07, Brantley Coile <brantley@coraid.com> wrote:
> I've got some heartburn about upas/fs.  Seems our
> user base is growing larger than main memories of our
> imap servers.  Anyone have any ideas to keep systems from
> running out of memory?  Anyone using something that
> virtual memory to keep the mail boxes?
>
>
>
>

Re: [9fans] Anyone working on new upas/fs?

[Russ Cox]

> I've got some heartburn about upas/fs.  Seems our
> user base is growing larger than main memories of our
> imap servers.  Anyone have any ideas to keep systems from
> running out of memory?  Anyone using something that
> virtual memory to keep the mail boxes?

Plan9ports has a new upas/fs (called mailfs for now,
and in $PLAN9/src/cmd/upas/nfs) with only an IMAP
back end, but it demand loads from the IMAP server.
I structured it so that it should not be hard to add a
module for reading local mailboxes too; those could
be loaded on demand as well.  Also, the existence of
the on-demand loading means one can treat memory
as a cache, tossing out messages as memory fills
and reloading them as needed.  One could even keep
a local disk cache of message pieces instead of requerying
a remote mailbox.

The hard part of adding local mailbox support should be
finding your place when the mailbox has changed underfoot,
not any structural part of the fs.

Russ

Re: [9fans] Anyone working on new upas/fs?

[erik quanstrom]

is the format of nfs/mbox/n/* still incompatable with upas/fs?

- erik

Re: [9fans] Anyone working on new upas/fs?

[Russ Cox]

> is the format of nfs/mbox/n/* still incompatable with upas/fs?

Yes.  (It's better!)

Russ

Re: [9fans] Anyone working on new upas/fs?

[erik quanstrom]

russ,

i believe it's better, but it's awful hard to retrofit everything that depends
on the format of upas/fs files.  ned, acme, faces, imap4d, pop3d, etc.  that seems like
too much disruption.  (but i'll bite if you rewrite all of upas :-).)

is there anything fundamentally incompatable in nfs?

- erik

Re: [9fans] Anyone working on new upas/fs?

[Russ Cox]

> i believe it's better, but it's awful hard to retrofit everything that depends
> on the format of upas/fs files.  ned, acme, faces, imap4d, pop3d, etc.  that seems like
> too much disruption.  (but i'll bite if you rewrite all of upas :-).)
>
> is there anything fundamentally incompatable in nfs?

ned acme faces all have the new code (in plan9ports) already.
if you don't want to use the new code, you don't have to.
it would be easy to change nfs to present the old interface too.

i am not actively working on it, just describing it so others can
if they wish.

russ