[Dovecot] Fwd: NFS question
Resent to list, since my previous direct emails to Timo have gone unanswered I am NOT a member of this list so Timo please reply direct
I do not wish responses from those who are not developers of dovecot, many I have since had discussions with on another list and spam binned (abusive souls like charlie marcus) some for trolling, I seek a definitive answer and there is only one man who can give this, but I likely was mailing a old address he doesn't read
---------- Forwarded message ---------- From: Nick Edwards nick.z.edwards@gmail.com Date: Fri, Sep 24, 2010 at 6:15 PM Subject: NFS question To: timo@iki.fi
After reading the archives recently on a few threads about NFS I have concerns over our plans to move from cyrus to dovecot, we initially discounted dovecot as a choice over it, but since dovecot and sieve go well together, I am just re-capping everything before we approve move to courier or back to dovecot, having re read those threads over a couple of times, am I right in assuming that this caching problem, is really only a problem if using imap and the chances of it being an issue with pop3 is very rare? If this is the case, then we certainly would approve move to dovecot.
I note some people who have apparently much larger systems than us, say that they have seen no problems but others say they may have had just not noticed.
So, if smtp3 delivers to storage MailDir and pop3-1 connects to get mail - at the same time: no problem just wont see that message until next refresh at the same time: will see message
if smtp3 and smtp1 deliver at same time there lies the corruption issue? If so, it will be reindexed at next delivery or pop3?
Just trying to understand where it will be a problem, we will use postfix setting of virtual_transport = dovecot and dovecot_destination_recipient_limit = 1
We dont allow multiple logins either, we have only intention for one imap server, to compliment our two pop3's and 4 smtp's.
We intend to use -
pop3_lock_session=yes maildir_very_dirty_syncs=yes auth_verbose = yes auth_cache_size = 512 auth_cache_ttl = 3600 auth_cache_negative_ttl = 0 mail_location = maildir:/var/vmail/%1d/%d/%n/Maildir mmap_disable = yes mail_nfs_storage = yes mail_nfs_index = yes
protocol lda { mail_plugins = quota cmusieve quota_full_tempfail = yes auth_socket_path = /var/run/dovecot/auth-master }
Also, will this be more of a problem if we use dovecot v1.2 or v2.0 ? (only examples of configs we have for our move is for v1.2 at present for debian)
Hope you do not mind me asking this in private, but given how those threads ended up in personal attacks, I would rather not reignite any fires.
Nick
On 2010-09-29 1:27 AM, Nick Edwards wrote:
I do not wish responses from those who are not developers of dovecot,
Then you should have spent the few seconds required to browse the PUBLIC list archives for Timo's current email address - then I wouldn't have even seen this message and you wouldn't be getting this response.
many I have since had discussions with on another list and spam binned (abusive souls like charlie marcus)
If you consider simply correcting your misunderstanding of how dovecot works as 'abusive', then, yeah, I guess I'm guilty as charged.
but I likely was mailing a old address he doesn't read
Like I said - took me all of 10 seconds to determine his current email address from his most recent posting to this list (he posts daily).
--
Best regards,
Charles
On Wed, 29 Sep 2010, Charles Marcus wrote:
On 2010-09-29 1:27 AM, Nick Edwards wrote:
I do not wish responses from those who are not developers of dovecot,
Silly...
Then you should have spent the few seconds required to browse the PUBLIC list archives for Timo's current email address - then I wouldn't have even seen this message and you wouldn't be getting this response.
Additionally, I don't think this is something the developer needs to address privately.
There's also a whole thread about this, and this reply totally cleared up the issue for me:
http://www.mail-archive.com/dovecot@dovecot.org/msg31713.html
Charles
many I have since had discussions with on another list and spam binned (abusive souls like charlie marcus)
If you consider simply correcting your misunderstanding of how dovecot works as 'abusive', then, yeah, I guess I'm guilty as charged.
but I likely was mailing a old address he doesn't read
Like I said - took me all of 10 seconds to determine his current email address from his most recent posting to this list (he posts daily).
--
Best regards,
Charles
On Wed, 2010-09-29 at 15:27 +1000, Nick Edwards wrote:
To: timo@iki.fi
This has never been my email address. I don't know who it goes to.
After reading the archives recently on a few threads about NFS I have concerns
You've read http://dovecot.org/list/dovecot/2010-August/052188.html thread?
over our plans to move from cyrus to dovecot, we initially discounted dovecot as a choice over it, but since dovecot and sieve go well together, I am just re-capping everything before we approve move to courier or back to dovecot, having re read those threads over a couple of times, am I right in assuming that this caching problem, is really only a problem if using imap and the chances of it being an issue with pop3 is very rare?
With POP3-only users it should be rare. But if they're using webmail also that adds IMAP there which makes it less safe. Also with POP3 you might want to disable indexes anyway and use filename as POP3 UIDL and then corruption wouldn't matter at all (dovecot-uidlist file updates are actually pretty pointless then).
Also, will this be more of a problem if we use dovecot v1.2 or v2.0 ?
They work identically. Although today I made performance improvements to POP3, and I'll probably still make some more.
Anyway, I can't give you any guarantees. I only know that it's not 100% safe, but some people with POP3-only/mostly setups have been happy enough anyway.
On 2010-09-29 5:52 PM, Timo Sirainen wrote:
Anyway, I can't give you any guarantees. I only know that it's not 100% safe, but some people with POP3-only/mostly setups have been happy enough anyway.
Timo, can you at least clarify this - my understanding is that the problem here is not inherent to dovecot, but to NFS caching, and that dovecot is no more or less prone to having problems than any other imap/pop3 server?
--
Best regards,
Charles
On 2010-09-29 5:52 PM, Timo Sirainen wrote:
Anyway, I can't give you any guarantees. I only know that it's not 100% safe, but some people with POP3-only/mostly setups have been happy enough anyway.
Timo, can you at least clarify this - my understanding is that the problem here is not inherent to dovecot, but to NFS caching, and that dovecot is no more or less prone to having problems than any other imap/pop3 server?
That is correct. Except that many other imap/pop servers do not implement a message index to increase performance. The problem lies in the index, not in the messages themselves. You can turn off the index completely, and then you'll be just as slow as any other imap server and wont ever see this problem.
Or you can turn off index updating in the LDA if you use the LDA, and that prevents a big part of the issue as well.
Or you implement the dovecot director.
Cor
On 2010-09-30 7:38 AM, Cor Bosman wrote:
Charles wrote:
Timo, can you at least clarify this - my understanding is that the problem here is not inherent to dovecot, but to NFS caching, and that dovecot is no more or less prone to having problems than any other imap/pop3 server?
That is correct. Except that many other imap/pop servers do not implement a message index to increase performance. The problem lies in the index, not in the messages themselves.
Right, I knew that, just wasn't clear...
You can turn off the index completely, and then you'll be just as slow as any other imap server and wont ever see this problem.
But we're talking strictly POP3 here, so indexes aren't useful (and therefor can be disabled completely if all you are using dovecot for is as a POP3 server) anyway, right?
As for IMAP, I think Timo also made it clear that if you weren't using the dovecot LDA+index updating, or if the indexes weren't stored on NFS, then IMAP didn't suffer the problem/issue as well... ?
I'm just glad I don't have to use NFS, so I'm asking just for the sake of knowing (and in case I ever do need to use NFS)... :)
--
Best regards,
Charles
On Thu, 2010-09-30 at 08:28 -0400, Charles Marcus wrote:
As for IMAP, I think Timo also made it clear that if you weren't using the dovecot LDA+index updating, or if the indexes weren't stored on NFS, then IMAP didn't suffer the problem/issue as well... ?
It's not just indexes, it's also dovecot-uidlist file updates. Indexes get a lot more easily corrupted, but I think even when you disable indexes there are some problems with uidlist file too. But I'm not entirely sure about that, few people have used that kind of an installation.
On 9/30/2010 7:28 AM, Charles Marcus wrote:
On 2010-09-30 7:38 AM, Cor Bosman wrote:
Charles wrote:
Timo, can you at least clarify this - my understanding is that the problem here is not inherent to dovecot, but to NFS caching, and that dovecot is no more or less prone to having problems than any other imap/pop3 server?
That is correct. Except that many other imap/pop servers do not implement a message index to increase performance. The problem lies in the index, not in the messages themselves.
Right, I knew that, just wasn't clear...
You can turn off the index completely, and then you'll be just as slow as any other imap server and wont ever see this problem.
But we're talking strictly POP3 here, so indexes aren't useful (and therefor can be disabled completely if all you are using dovecot for is as a POP3 server) anyway, right?
Just to clarify, we are talking strictly pop3 w/maildir. Indexing is quite useful for pop3 w/mbox.
Ken Pacific.Net
As for IMAP, I think Timo also made it clear that if you weren't using the dovecot LDA+index updating, or if the indexes weren't stored on NFS, then IMAP didn't suffer the problem/issue as well... ?
I'm just glad I don't have to use NFS, so I'm asking just for the sake of knowing (and in case I ever do need to use NFS)... :)
-- Ken Anderson Pacific Internet - http://www.pacific.net
participants (6)
-
Charles Marcus
-
Charles Sprickman
-
Cor Bosman
-
Ken A
-
Nick Edwards
-
Timo Sirainen