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
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)
> ..
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
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 h
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
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 (s
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 chang
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 sto
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 d
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)
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),
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.
signatur
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 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 los
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 i
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 http://wiki2.do
On Wed, Jan 18, 2012 at 8:39 PM, Stan Hoeppner 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 LMTP
>>>
>
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
>>
>>
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
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
>
>
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!
> > unfor
On Wed, Jan 18, 2012 at 9:58 AM, Timo Sirainen 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 of t
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
>>> architectur
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 o
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 s
>>> * 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 P
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 se
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
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 see
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 ou
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'
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
zlib_
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 bra
33 matches
Mail list logo
