On Thu, Feb 09, 2012 at 01:48:09AM +0200, Timo Sirainen wrote:
On 7.2.2012, at 10.25, Jan-Frode Myklebust wrote:
Feb 6 16:13:10 loadbalancer2 dovecot: lmtp(6601): Panic: file
lmtp-proxy.c: line 376 (lmtp_proxy_output_timeout): assertion failed:
(proxy-data_input-eof)
..
Should I
On 9.2.2012, at 14.56, Jan-Frode Myklebust wrote:
Should I try increasing LMTP_PROXY_DATA_INPUT_TIMEOUT_MSECS, or do you have
any
other ideas for what might be causing it ?
The backend server didn't reply within LMTP_PROXY_DEFAULT_TIMEOUT_MSECS
(30 secs).
It's actually 60 sec in v2.0
On 7.2.2012, at 10.25, Jan-Frode Myklebust wrote:
Feb 6 16:13:10 loadbalancer2 dovecot: lmtp(6601): Panic: file
lmtp-proxy.c: line 376 (lmtp_proxy_output_timeout): assertion failed:
(proxy-data_input-eof)
..
Should I try increasing LMTP_PROXY_DATA_INPUT_TIMEOUT_MSECS, or do you have
On Mon, Feb 06, 2012 at 10:01:03PM +0100, Jan-Frode Myklebust wrote:
Your fsyncs can run over 60 seconds?
Hopefully not.. maybe just me being confused by the error message about
lmtp_proxy_output_timeout. After adding
http://hg.dovecot.org/dovecot-2.0/rev/71084b799a6c on friday, we haven't
On 3.2.2012, at 14.25, Jan-Frode Myklebust wrote:
I now implemented this patch on our directors, and pointed postfix at them.
No problem seen so far, but I'm still a bit uncertain about the
LMTP_PROXY_DATA_INPUT_TIMEOUT_MSECS. I know we're experienceing quite
large delays when fsync'ing (slow
On Mon, Feb 06, 2012 at 10:29:03PM +0200, Timo Sirainen wrote:
On 3.2.2012, at 14.25, Jan-Frode Myklebust wrote:
I now implemented this patch on our directors, and pointed postfix at them.
No problem seen so far, but I'm still a bit uncertain about the
LMTP_PROXY_DATA_INPUT_TIMEOUT_MSECS.
On Wed, Jan 18, 2012 at 09:03:18PM +0200, Timo Sirainen wrote:
I think the way I originally planned LMTP proxying to work is simply too
complex to work reliably, perhaps even if the code was bug-free. So
instead of reading+writing DATA at the same time, this patch changes the
On 20.1.2012, at 4.27, Stan Hoeppner wrote:
I spent months looking into NFS related issues. I read through Linux and
FreeBSD kernel source codes to figure out if there's something I could do to
avoid the problems I see. I sent some patches to try to improve things,
which of course didn't
On 20.1.2012, at 9.43, Robert Schetterer wrote:
i.e i think it should be poosible to design partitioning with ldap or sql
to i.e split up heavy and big mailboxes in seperate storage partitions etc
am i right here Timo ?
You can use per-user home or mail_location that points to different
On Wed, Jan 18, 2012 at 8:39 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
On 1/18/2012 7:54 AM, Timo Sirainen wrote:
On Wed, 2012-01-18 at 20:44 +0800, Lee Standen wrote:
* All mail storage presented via NFS over 10Gbps Ethernet (Jumbo Frames)
* Postfix will feed new email to Dovecot via
On 19.1.2012, at 6.39, Stan Hoeppner wrote:
You're going to run into NFS caching troubles with the above split
setup. I don't recommend it. You will see error messages about index
corruption with it, and with dbox it can cause metadata loss.
http://wiki2.dovecot.org/NFS
On 19.1.2012, at 19.08, Mark Moseley wrote:
namespace {
separator = /
prefix = #mbox/
location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=MEMORY
inbox = yes
hidden = yes
list = no
}
Client access to new mail might be a little slower, but if it eliminates
the index corruption issue
On 1/19/2012 1:18 PM, Timo Sirainen wrote:
On 19.1.2012, at 6.39, Stan Hoeppner wrote:
You're going to run into NFS caching troubles with the above split
setup. I don't recommend it. You will see error messages about index
corruption with it, and with dbox it can cause metadata loss.
On 20.1.2012, at 1.51, Stan Hoeppner wrote:
I spent a decent amount of time last night researching the NFS cache
issue. It seems there is no way to completely disable NFS client
caching (in lie of rewriting the code oneself--a daunting tak), which
would seem to be the real solution to the
On Fri, 2012-01-20 at 02:13 +0200, Timo Sirainen wrote:
There are several huge Dovecot+NFS setups. They use director. It works well
enough (and with the recent fixes, I'd hope perfectly).
Not to mention other huge NFS setups that don't use director, and also
have no problems.
On 1/19/2012 6:13 PM, Timo Sirainen wrote:
On 20.1.2012, at 1.51, Stan Hoeppner wrote:
I spent a decent amount of time last night researching the NFS cache
issue. It seems there is no way to completely disable NFS client
caching (in lie of rewriting the code oneself--a daunting tak), which
Am 20.01.2012 01:13, schrieb Timo Sirainen:
On 20.1.2012, at 1.51, Stan Hoeppner wrote:
I spent a decent amount of time last night researching the NFS cache
issue. It seems there is no way to completely disable NFS client
caching (in lie of rewriting the code oneself--a daunting tak), which
Hi Guys,
I've been desperately trying to find some comparative performance
information about the different mailbox formats supported by Dovecot in
order to make an assessment on which format is right for our environment.
This is a brand new build, with customer mailboxes to be migrated in
Am 18.01.2012 13:44, schrieb Lee Standen:
Hi Guys,
I've been desperately trying to find some comparative performance
information about the different mailbox formats supported by Dovecot in
order to make an assessment on which format is right for our environment.
This is a brand new
Spanish edu site here, 80k users, 4,5 TB of email, 6.000 iops
(indexes) + 9.000 iops (mdboxes) in working hours here.
We evaluated mdbox against Maildir and we found that with these
setting dovecot 2 perfoms better than Maildir:
mdbox_rotate_interval = 1d
mdbox_rotate_size=60m
On Wed, 2012-01-18 at 20:44 +0800, Lee Standen wrote:
I've been desperately trying to find some comparative performance
information about the different mailbox formats supported by Dovecot in
order to make an assessment on which format is right for our environment.
Unfortunately there aren't
On 18.01.2012 21:54, Timo Sirainen wrote:
On Wed, 2012-01-18 at 20:44 +0800, Lee Standen wrote:
I've been desperately trying to find some comparative performance
information about the different mailbox formats supported by Dovecot
in
order to make an assessment on which format is right for
Out of interest, has the NFS issue been tested on NFS4? My
understanding is that NFS4 has a lot of fixes for the locking/caching
problems that plague NFS3, and we were planning to use NFS4 from day
one.
If this hasn't been tested, is there some kind of load simulator that
we could run to
On Wed, 2012-01-18 at 22:36 +0800, Lee Standen wrote:
How about this... are there any tools available (that you know of) to
capture real live customer POP3/IMAP traffic and replay it against a
separate system? That might be a feasible option for doing a
like-for-like comparison in our
On Wed, 2012-01-18 at 23:21 +0800, Lee Standen wrote:
Out of interest, has the NFS issue been tested on NFS4? My
understanding is that NFS4 has a lot of fixes for the locking/caching
problems that plague NFS3, and we were planning to use NFS4 from day
one.
I've tried with Linux NFS4
snip
* All mail storage presented via NFS over 10Gbps Ethernet (Jumbo Frames)
* Postfix will feed new email to Dovecot via LMTP
* Dovecot servers have been split based on their role
- Dovecot LDA Servers (running LMTP protocol)
- Dovecot POP/IMAP servers (running POP/IMAP protocols)
On 18.1.2012, at 19.54, Mark Moseley wrote:
I'm in the middle of working on a Maildir-mdbox migration as well,
and likewise, over NFS (all Netapps but moving to Sun), and likewise
with split LDA and IMAP/POP servers (and both of those served out of
pools). I was hoping doing things like
On Wed, Jan 18, 2012 at 07:58:31PM +0200, Timo Sirainen wrote:
--i.e. all the
suggestions at http://wiki2.dovecot.org/NFS. Is that definitely not
the case? Is there anything else (beyond moving to a director-based
architecture) that can mitigate the risk of index corruption? In our
On 18.1.2012, at 20.51, Jan-Frode Myklebust wrote:
On Wed, Jan 18, 2012 at 07:58:31PM +0200, Timo Sirainen wrote:
--i.e. all the
suggestions at http://wiki2.dovecot.org/NFS. Is that definitely not
the case? Is there anything else (beyond moving to a director-based
architecture) that can
On Wed, Jan 18, 2012 at 9:58 AM, Timo Sirainen t...@iki.fi wrote:
On 18.1.2012, at 19.54, Mark Moseley wrote:
I'm in the middle of working on a Maildir-mdbox migration as well,
and likewise, over NFS (all Netapps but moving to Sun), and likewise
with split LDA and IMAP/POP servers (and both
On Wed, Jan 18, 2012 at 09:03:18PM +0200, Timo Sirainen wrote:
On 18.1.2012, at 20.51, Jan-Frode Myklebust wrote:
What's the problem with director-based architecture?
It hasn't been working reliably for lmtp in v2.0.
Yes, besides that :)
Besides that it's great!
unfortunately I
On 18.1.2012, at 22.14, Jan-Frode Myklebust wrote:
unfortunately I haven't tested that patch, so I have no idea if it
fixed the issues or not...
I'm not sure if that patch is useful or not. The important patch to fix it
is http://hg.dovecot.org/dovecot-2.0/rev/71084b799a6c
So with that
On 18.1.2012, at 21.49, Mark Moseley wrote:
What's the problem with director-based architecture?
Nothing, per se. It's just that migrating to mdbox *and* to a director
architecture is quite a bit more added complexity than simply
migrating to mdbox alone.
Yes, I agree it's safer to do one
On 1/18/2012 7:54 AM, Timo Sirainen wrote:
On Wed, 2012-01-18 at 20:44 +0800, Lee Standen wrote:
* All mail storage presented via NFS over 10Gbps Ethernet (Jumbo Frames)
* Postfix will feed new email to Dovecot via LMTP
* Dovecot servers have been split based on their role
- Dovecot LDA
34 matches
Mail list logo
