I'm using ext3 with dir_hash. I considered using XFS, but there are a
lot of benchmarks that show that XFS is not faster in general, also the
XFS development seems to be stucked at the moment and from my own
experience as well as from other people in a recent thread on this
mailinglist there
Hello,
I did play with ext2 dir_hash, but didn't find it helping me much (it
would help lookups sometimes, but slowed file creation significantly on
my tests). I've also heard people praise reiserfs for it's performance
under these conditions (personally I don't trust it, but some of that is
On Thursday 09 November 2006 02:02, Paul Dekkers wrote:
> So maybe you're indeed facing the quality of your IMAP client
That can be a lot of it. I run a cyrus mail store on my local network and as
much as I like Kmail it is painfully slow opening folders with a lot of
messages (I have one with ~
On Thu, 9 Nov 2006, Marten Lehmann wrote:
That was merged a long time back. doc/text/changes:
is it enabled by default? Or do I have to specify which headers in
particular shall be cached?
It is enabled by default, but only applies to messages delivered after
you started to run 2.2.1 or lat
Sebastian Hagedorn wrote:
> -- Marten Lehmann <[EMAIL PROTECTED]> is rumored to have mumbled on 8.
> November 2006 17:02:52 +0100 regarding performance on large inboxes:
>
>> from time to time we have users with a very large inbox, which means it
>> contains 20.000 mess
Hello,
That was merged a long time back. doc/text/changes:
is it enabled by default? Or do I have to specify which headers in
particular shall be cached?
We are using 2.2.12, so then the patch be already included.
Regards
Marten
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wik
On 2006-11-08 at 22:04 +, David Carter wrote:
> On Wed, 8 Nov 2006, Phil Pennock wrote:
> >The relevant stuff is HERMES_CACHE_MOST in mailbox.c; I've really no
> >idea whether or not these changes are roughly independent and if they
> >can be pulled out.
>
> That was merged a long time back. d
On Wed, 8 Nov 2006, Phil Pennock wrote:
The relevant stuff is HERMES_CACHE_MOST in mailbox.c; I've really no
idea whether or not these changes are roughly independent and if they
can be pulled out.
That was merged a long time back. doc/text/changes:
Changes to the Cyrus IMAP Server since 2.2.
On 2006-11-08 at 21:58 +0100, Marten Lehmann wrote:
> I think it would be a really great performance boost if cyrus would
> cache all headers (I think that is what dovecot does and is very fast
> with it) so it doesn't have to touch the files. Where have you seen such
> patches?
Under http://ww
Hello,
What is fetched depends upon the client software and what it asks for.
yes, but that may very extremely. If Cyrus only caches lets say "X-Spam"
and there is no such header in the email and thus not in the cache, will
Cyrus look into the file then? Or will the cache contain an empty he
-- Marten Lehmann <[EMAIL PROTECTED]> is rumored to have mumbled on 8.
November 2006 17:02:52 +0100 regarding performance on large inboxes:
from time to time we have users with a very large inbox, which means it
contains 20.000 messages or even more. My quite general question is: What
is
On 2006-11-08 at 17:02 +0100, Marten Lehmann wrote:
> from time to time we have users with a very large inbox, which means it
> contains 20.000 messages or even more. My quite general question is:
> What is cyrus doing once a user logs in through imap or pop3? It seems,
> that it is parsing the
from time to time we have users with a very large inbox, which means it
contains 20.000 messages or even more. My quite general question is:
What is cyrus doing once a user logs in through imap or pop3? It seems, that
it is parsing the directory, which takes very long. But what does it have
the i
Hello,
from time to time we have users with a very large inbox, which means it
contains 20.000 messages or even more. My quite general question is:
What is cyrus doing once a user logs in through imap or pop3? It seems,
that it is parsing the directory, which takes very long. But what does
it
14 matches
Mail list logo
