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

This is a discussion on [9fans] Anyone working on new upas/fs? - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

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

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

    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?



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

    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 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?
    >
    >
    >
    >


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

    > 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

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

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

    - erik


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

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

    Yes. (It's better!)

    Russ

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

    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


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

    > 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

+ Reply to Thread