http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta8.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta8.tar.gz.sig
Changes since beta7:
- Added a new "raw" mail storage backend which allows opening files/streams as single mail mailboxes. deliver uses this now instead of opening the incoming mail as a mbox. So deliver should be now faster and it doesn't anymore remove Dovecot's private mbox headers if you're not using mbox.
- Cache file tracks message expunges again
- All kinds of other fixes
- Some optimizations
I think we're getting closer to v1.1 RCs.
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta8.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta8.tar.gz.sig
Changes since beta7:
- Added a new "raw" mail storage backend which allows opening files/streams as single mail mailboxes. deliver uses this now instead of opening the incoming mail as a mbox. So deliver should be now faster and it doesn't anymore remove Dovecot's private mbox headers if you're not using mbox.
- Cache file tracks message expunges again
- All kinds of other fixes
- Some optimizations
I think we're getting closer to v1.1 RCs.
I just installed beta 8 and everything appears to be running smoothly.
Of course, my mail server is pretty basic.
Do I need to delete the cache files with the above fix, or is it fine with the old cache files?
Jeff
On 11.11.2007, at 20.43, Jeff Grossman wrote:
- Cache file tracks message expunges again
- All kinds of other fixes
- Some optimizations
I think we're getting closer to v1.1 RCs.
I just installed beta 8 and everything appears to be running
smoothly. Of course, my mail server is pretty basic.Do I need to delete the cache files with the above fix, or is it
fine with the old cache files?
You can keep them, it just might take longer for them to get
compressed. The rule is that when 20% of the cache file contains
deleted data, it's compressed.
Timo Sirainen wrote:
On 11.11.2007, at 20.43, Jeff Grossman wrote:
- Cache file tracks message expunges again
- All kinds of other fixes
- Some optimizations
I think we're getting closer to v1.1 RCs.
I just installed beta 8 and everything appears to be running smoothly. Of course, my mail server is pretty basic.
Do I need to delete the cache files with the above fix, or is it fine with the old cache files?
You can keep them, it just might take longer for them to get compressed. The rule is that when 20% of the cache file contains deleted data, it's compressed.
OK. Thanks for the info.
Jeff
On Sun, Nov 11, 2007 at 10:43:34AM -0800, Jeff Grossman wrote:
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta8.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta8.tar.gz.sig
Changes since beta7:
- Added a new "raw" mail storage backend which allows opening files/streams as single mail mailboxes. deliver uses this now instead of opening the incoming mail as a mbox. So deliver should be now faster and it doesn't anymore remove Dovecot's private mbox headers if you're not using mbox.
- Cache file tracks message expunges again
- All kinds of other fixes
- Some optimizations
I think we're getting closer to v1.1 RCs.
I just installed beta 8 and everything appears to be running smoothly. Of course, my mail server is pretty basic.
Jeff
I also installed 1.1b8 yesterday and everything has been fine so far. Haven't found anything yet to request a patch for :)
I even took a leap and migrated my 6 gigs of personal email to my server running 1.1b8 and am using it as my exclusive working mail set. My next task is to convince a few more heavy users here to do the same (I'm sure I won't need to twist their arm very hard).
My email use today has been bliss, while hearing about co-workers complain about the old slow production server! hahahahaha.
Tere.
I think we're getting closer to v1.1 RCs.
I'm a little bit confused. Right now I'm using v.1.0.7, but I tried compile v1.1.beta8 with same options as v.1.0.7 and seems it's working fine like stable version does.
But if v1.1 is beta then what is/will be v2? And what version should I use?
-- Sysadmin
On 12.11.2007 15:24, Mart Pirita wrote:
Tere.
I think we're getting closer to v1.1 RCs.
I'm a little bit confused. Right now I'm using v.1.0.7, but I tried compile v1.1.beta8 with same options as v.1.0.7 and seems it's working fine like stable version does.
But if v1.1 is beta then what is/will be v2? And what version should I use?
You should use stable releases if you want stable environment. Beta may work just fine in simple scenarios but in complex configs it may crash.
Timo Sirainen wrote:
Changes since beta7:
- Added a new "raw" mail storage backend which allows opening files/streams as single mail mailboxes. deliver uses this now instead of opening the incoming mail as a mbox. So deliver should be now faster and it doesn't anymore remove Dovecot's private mbox headers if you're not using mbox.
Does this allow for the potential of a SQL backend?
-- Daniel
On Mon, 2007-11-12 at 07:27 -0800, Daniel L. Miller wrote:
Timo Sirainen wrote:
Changes since beta7:
- Added a new "raw" mail storage backend which allows opening files/streams as single mail mailboxes. deliver uses this now instead of opening the incoming mail as a mbox. So deliver should be now faster and it doesn't anymore remove Dovecot's private mbox headers if you're not using mbox.
Does this allow for the potential of a SQL backend?
SQL backend has been possible for a long time and there's already a kind-of working version available: http://dovecot.org/patches/mail-sql.tar.gz
Probably doesn't compile with latest v1.1 anymore though.
Timo Sirainen wrote:
On Mon, 2007-11-12 at 07:27 -0800, Daniel L. Miller wrote:
Timo Sirainen wrote:
Changes since beta7:
- Added a new "raw" mail storage backend which allows opening files/streams as single mail mailboxes. deliver uses this now instead of opening the incoming mail as a mbox. So deliver should be now faster and it doesn't anymore remove Dovecot's private mbox headers if you're not using mbox.
Does this allow for the potential of a SQL backend?
SQL backend has been possible for a long time and there's already a kind-of working version available: http://dovecot.org/patches/mail-sql.tar.gz
Probably doesn't compile with latest v1.1 anymore though.
Hey that's cool - didn't realise this was available . Timo what is your own opinion of sql based mail storage vs maildir (or dbox)? When is it a good idea?
On Mon, 2007-11-12 at 16:27 +0000, Daniel Watts wrote:
SQL backend has been possible for a long time and there's already a kind-of working version available:
Wasted a bit of time getting it to work again. It's horribly inefficient when saving messages and EXPUNGE seems to be somewhat broken, but at least it kinda works. :)
http://dovecot.org/patches/mail-sql.patch http://dovecot.org/patches/mail-sql.tar.gz
Unpack mail-sql.tar.gz to src/plugins/, apply the patch, run autogen.sh and configure. Use:
mail_location = sql:pgsql:dbname=mails host=localhost user=foo password=bar
(the key=value pairs are named the same as in dovecot-sql.conf)
Hey that's cool - didn't realise this was available . Timo what is your own opinion of sql based mail storage vs maildir (or dbox)? When is it a good idea?
I don't really know. Maybe if you want to use the mail database for something special. Performance definitely isn't a reason.
I'm not sure if this would allow multi-master replication though. I know MySQL offers support for it, but what happens when both masters have added a row that causes a unique key collision? Can you write triggers to fix those cases automatically?
On Mon, 2007-11-12 at 20:07 +0200, Timo Sirainen wrote:
On Mon, 2007-11-12 at 16:27 +0000, Daniel Watts wrote:
SQL backend has been possible for a long time and there's already a kind-of working version available:
Hey that's cool - didn't realise this was available . Timo what is your own opinion of sql based mail storage vs maildir (or dbox)? When is it a good idea?
I don't really know. Maybe if you want to use the mail database for something special. Performance definitely isn't a reason.
I'm not sure if this would allow multi-master replication though. I know MySQL offers support for it, but what happens when both masters have added a row that causes a unique key collision? Can you write triggers to fix those cases automatically?
It's taken care of in Mysql 5.0. There's a couple settings: auto_increment_increment = 10 auto_increment_offset = 1 auto_increment_offset = 2 (for other master)
to keep keys assigned by the servers from colliding. Here's a link I was just checking out today.. http://capttofu.livejournal.com/1752.html?view=20440#t20440
If mail-sql was efficient, I'd love to go that route - imagine disaster recovery, or even geographical load balancing, being as easy as adding another replication master....
Rick
On 12.11.2007, at 20.14, Rick Romero wrote:
I'm not sure if this would allow multi-master replication though.
I know MySQL offers support for it, but what happens when both masters have added a row that causes a unique key collision? Can you write
triggers to fix those cases automatically?It's taken care of in Mysql 5.0. There's a couple settings: auto_increment_increment = 10 auto_increment_offset = 1 auto_increment_offset = 2 (for other master)
I know that takes care of autoincrement keys, but it's not enough.
There are several other unique keys that can't be handled like that.
Most importantly IMAP UIDs. They must always be increasing. Another
example would be newly created mailbox names.
On Mon, 2007-11-12 at 21:30 +0200, Timo Sirainen wrote:
On 12.11.2007, at 20.14, Rick Romero wrote:
I'm not sure if this would allow multi-master replication though.
I know MySQL offers support for it, but what happens when both masters have added a row that causes a unique key collision? Can you write
triggers to fix those cases automatically?It's taken care of in Mysql 5.0. There's a couple settings: auto_increment_increment = 10 auto_increment_offset = 1 auto_increment_offset = 2 (for other master)
I know that takes care of autoincrement keys, but it's not enough.
There are several other unique keys that can't be handled like that.
Most importantly IMAP UIDs. They must always be increasing.
Actually it wouldn't be enough to handle duplicate key collisions. It would have to be able to handle a situation like:
master 1: add UID 100 master 1: expunge UID 100 master 2: add UID 100
When 1 and 2 are synchronized, master2's UID 100 needs to be given a new UID. If replication runs pre-insert triggers, maybe this could be implemented by keeping track of "next UID" and then if a new UID is added with less than that, its UID would be changed (and also existing UIDs with that or a higher value so client doesn't cache wrong messages).
The above should still happen only rarely when masters aren't communicating with each others. If replication is done asynchronously that could easily happen all the time and it wouldn't work well. It could be prevented with some kind of global locks/sequences. Does MySQL cluster support them?
And what about PostgreSQL's multi-master replication? :) The current mail-sql code works only with it.
On Mon, 2007-11-12 at 21:58 +0200, Timo Sirainen wrote:
And what about PostgreSQL's multi-master replication? :)
PGCluster's description makes it sound like the multi-master clustered database looks and behaves exactly as a non-clustered database. So that sounds promising. Although I'd like to know how it behaves when connection between two masters goes down and they both start doing independent changes to the database..
On Mon, 2007-11-12 at 20:07 +0200, Timo Sirainen wrote:
Wasted a bit of time getting it to work again. It's horribly inefficient when saving messages and EXPUNGE seems to be somewhat broken, but at least it kinda works. :)
http://dovecot.org/patches/mail-sql.patch http://dovecot.org/patches/mail-sql.tar.gz
Oh, and it requires the latest v1.1 code tree from hg (or the next nightly snapshot). I did a few fixes to lib-sql.
On Mon, 12 Nov 2007, Timo Sirainen wrote:
On Mon, 2007-11-12 at 20:07 +0200, Timo Sirainen wrote:
Wasted a bit of time getting it to work again. It's horribly inefficient when saving messages and EXPUNGE seems to be somewhat broken, but at least it kinda works. :)
http://dovecot.org/patches/mail-sql.patch http://dovecot.org/patches/mail-sql.tar.gz
Oh, and it requires the latest v1.1 code tree from hg (or the next nightly snapshot). I did a few fixes to lib-sql.
Why not maintain the patch as an hg branch and tell people to get it that way?
-- Asheesh.
-- Prices subject to change without notice.
On Tue, 2007-11-13 at 08:10 +0900, Asheesh Laroia wrote:
On Mon, 12 Nov 2007, Timo Sirainen wrote:
On Mon, 2007-11-12 at 20:07 +0200, Timo Sirainen wrote:
Wasted a bit of time getting it to work again. It's horribly inefficient when saving messages and EXPUNGE seems to be somewhat broken, but at least it kinda works. :)
http://dovecot.org/patches/mail-sql.patch http://dovecot.org/patches/mail-sql.tar.gz
Oh, and it requires the latest v1.1 code tree from hg (or the next nightly snapshot). I did a few fixes to lib-sql.
Why not maintain the patch as an hg branch and tell people to get it that way?
I guess I'm just lazy. :)
participants (9)
-
Adam McDougall
-
Asheesh Laroia
-
Daniel L. Miller
-
Daniel Watts
-
Jeff Grossman
-
Mart Pirita
-
Nikolay Shopik
-
Rick Romero
-
Timo Sirainen