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.
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
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 :)
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
On 26/04/2013 00:15, grarpamp wrote:
maildir format scale[s] quite well; pretty much the only
limitation is storage I/O.
Depending on your FS and horsepower, anything over
1000 x (n * 10) files in a directory can start to sink you
pretty quick. I've always wondered if there's a maildir split
I've always wondered if there's a maildir split
specified out there that applications could utilize...
where n is your split width... tmp/n, new/n, cur/n.
what about shifting this problem to the storage layer?
Apart using SSDs, what about using having a striped array as a RAID 1+0
layout,
post...@netorbit.it:
On 26/04/2013 00:15, grarpamp wrote:
maildir format scale[s] quite well; pretty much the only
limitation is storage I/O.
Depending on your FS and horsepower, anything over
1000 x (n * 10) files in a directory can start to sink you
pretty quick. I've always wondered
Am 26.04.2013 13:20, schrieb Wietse Venema:
post...@netorbit.it:
On 26/04/2013 00:15, grarpamp wrote:
maildir format scale[s] quite well; pretty much the only
limitation is storage I/O.
Depending on your FS and horsepower, anything over
1000 x (n * 10) files in a directory can start to sink
specified out there that applications could utilize...
where n is your split width... tmp/n, new/n, cur/n.
alternate you may use mdbox
http://wiki2.dovecot.org/MailboxFormat/dbox
Both of these hold all messages in a single directory.
So sdbox would be no advantage there.
And mdbox does not
Am 26.04.2013 21:24, schrieb grarpamp:
specified out there that applications could utilize...
where n is your split width... tmp/n, new/n, cur/n.
alternate you may use mdbox
http://wiki2.dovecot.org/MailboxFormat/dbox
Both of these hold all messages in a single directory.
So sdbox
Quoting grarpamp grarp...@gmail.com:
specified out there that applications could utilize...
where n is your split width... tmp/n, new/n, cur/n.
alternate you may use mdbox
http://wiki2.dovecot.org/MailboxFormat/dbox
Both of these hold all messages in a single directory.
So sdbox would be
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
Am 26.04.2013 21:24, schrieb grarpamp:
specified out there that applications could utilize...
where n is your split width... tmp/n, new/n, cur/n.
alternate you may use mdbox
http://wiki2.dovecot.org/MailboxFormat/dbox
Both of these hold all messages in a single directory.
So sdbox would
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*
I realize that this is off topic, but as there are more email experts
assembled here than any where else I know of
I have a couple of users who are using their maildir as online storage
for emails (current and archival).
They have done this on their own and are prepared to live with some
On 04/25/2013 08:56 PM, John Allen wrote:
I realize that this is off topic, but as there are more email experts
assembled here than any where else I know of
I have a couple of users who are using their maildir as online storage
for emails (current and archival).
They have done this on
maildir format scale[s] quite well; pretty much the only
limitation is storage I/O.
Depending on your FS and horsepower, anything over
1000 x (n * 10) files in a directory can start to sink you
pretty quick. I've always wondered if there's a maildir split
specified out there that applications
17 matches
Mail list logo
