Loading ...
Sorry, an error occurred while loading the content.

Re: OT - mail archive

Expand Messages
  • Stan Hoeppner
    ... True. mbox solved this problem before it really began, back before people started mass archiving thousands or tens of thousands of emails. When used with
    Message 1 of 17 , Apr 26, 2013
    • 0 Attachment
      On 4/26/2013 9:32 PM, grarpamp wrote:
      >>>>>>> specified out there that applications could utilize...
      >>>>>>> where n is your split width... tmp/n, new/n, cur/n.
      >
      >> pff and you realized that the "not a file per message" is
      >> exactly the solution for problems with tens thousands of
      >
      > It is *a* solution, not *the* solution,

      True. mbox solved this problem before it really began, back before
      people started mass archiving thousands or tens of thousands of emails.
      When used with modern MUAs and multiple name spaces you can mitigate or
      eliminate the locking problems, especially if using sieve to sort to
      these folders/files during delivery.

      I've been using such a setup with Dovecot, Thunderbird, and Roundcube,
      for may years. The largest of my mbox files, XFS list mail, is only
      19K+ emails. Full text searching it is relatively quick even if the FTS
      index isn't primed, and especially given the age of the hardware. If I
      was using maildir storage I can only assume FTS would take quite a while
      longer, as well as backup.

      --
      Stan
    • grarpamp
      ... I must admit giving yourself the local equivalent of your own lifetime email account is an interesting approach if you don t really need access to the raw
      Message 2 of 17 , Apr 26, 2013
      • 0 Attachment
        > re: the last two posts

        I must admit giving yourself the local equivalent
        of your own lifetime email account is an interesting
        approach if you don't really need access to the raw
        message files on disk.
      • Reindl Harald
        ... boy you replied to Faster disks don t solve algorithmic problems (problems related to the number of files per directory) with And mdbox does not support
        Message 3 of 17 , Apr 27, 2013
        • 0 Attachment
          Am 27.04.2013 04:32, schrieb grarpamp:
          >>>>>>> specified out there that applications could utilize...
          >>>>>>> where n is your split width... tmp/n, new/n, cur/n.
          >
          >> pff and you realized that the "not a file per message" is
          >> exactly the solution for problems with tens thousands of
          >
          > It is *a* solution, not *the* solution, and obviously not one
          > of the type I describes. And a fine pff to you my friend.

          boy you replied to "Faster disks don't solve algorithmic problems
          (problems related to the number of files per directory)" with
          "And mdbox does not support one message per file"

          no it is not *the* solution, but "does not support one message
          püer file is pure bullshit in this context because it is what
          you want
        • grarpamp
          ... No, actually right up there is what I was surveying. But you failed to grok that in your search for more pfft. I m sure it s a nice day, go outside :)
          Message 4 of 17 , Apr 27, 2013
          • 0 Attachment
            >> specified out there that applications could utilize...
            >> where n is your split width... tmp/n, new/n, cur/n.

            > it is what you want

            No, actually right up there is what I was surveying.
            But you failed to grok that in your search for more pfft.
            I'm sure it's a nice day, go outside :)
          • Reindl Harald
            ... maybe you should learn how to use a mail-client and quote before you post to a mail-server list - your answer above makes no sense at all in context of the
            Message 5 of 17 , Apr 27, 2013
            • 0 Attachment
              Am 27.04.2013 23:03, schrieb grarpamp:
              >>> specified out there that applications could utilize...
              >>> where n is your split width... tmp/n, new/n, cur/n.
              >
              >> it is what you want
              >
              > No, actually right up there is what I was surveying.
              > But you failed to grok that in your search for more pfft.
              > I'm sure it's a nice day, go outside :)

              maybe you should learn how to use a mail-client and quote
              before you post to a mail-server list - your answer above
              makes no sense at all in context of the thread
            Your message has been successfully submitted and would be delivered to recipients shortly.