Should work again with maildir.
Some bugfixes to indexes (possibly fixing the still persisting maildir sync errrors?)
Enabled cache file again. If client asks about something that can be cached for future, it's done. There's currently no smart logic about when not to do it or when to cache more than was asked for future use. Currently nothing is ever deleted from cache. Currently it's disabled if mmap_disable = yes.
Removed UIDPLUS extension after all. It needs more thinking with maildir, because for performance reasons new messages are given UIDs once at the end transaction rather than separately for each one. So, the UID would have to be 0 temporarily until transaction is committed. But the current API make the new messages visible without syncing, and then the sequences don't match anymore and we can't get the UIDs. So, this one needs thinking, mostly from API designing point of view.
On Mon, Jun 21, 2004 at 05:52:09PM +0300, Timo Sirainen wrote:
Should work again with maildir.
- Some bugfixes to indexes (possibly fixing the still persisting maildir sync errrors?)
Ah, gotta try that, but...
- Enabled cache file again. If client asks about something that can be cached for future, it's done. There's currently no smart logic about when not to do it or when to cache more than was asked for future use. Currently nothing is ever deleted from cache. Currently it's disabled if mmap_disable = yes.
...does that mean the cache-file will grow indefinitely?
- Removed UIDPLUS extension after all. It needs more thinking with maildir, because for performance reasons new messages are given UIDs once at the end transaction rather than separately for each one. So, the UID would have to be 0 temporarily until transaction is committed. But the current API make the new messages visible without syncing, and then the sequences don't match anymore and we can't get the UIDs. So, this one needs thinking, mostly from API designing point of view.
Actually I find the current maildir-performance quite amazing when compared to courier or bincimap. The only other imapd that can hold a candle to dovecot (at least according to my little-bit-out-dated and not-so-representative personal benchmarks) appears to be cyrus.
Anyways, as mentioned before, I'm still looking forward to the next Maildir-stable version. :-)
regards
On 21.6.2004, at 18:56, Moe Wibble wrote:
- Enabled cache file again. If client asks about something that can be cached for future, it's done. There's currently no smart logic about when not to do it or when to cache more than was asked for future use. Currently nothing is ever deleted from cache. Currently it's disabled if mmap_disable = yes.
...does that mean the cache-file will grow indefinitely?
Yes. Note the "currently" words there :) Will be fixed before 1.0 of course.
Actually I find the current maildir-performance quite amazing when compared to courier or bincimap. The only other imapd that can hold a candle to dovecot (at least according to my little-bit-out-dated and not-so-representative personal benchmarks) appears to be cyrus.
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needs to resync the whole maildir after each change in mailbox (and sometimes twice).
I guess we'll need a IMAP-optimized format sometimes soon.
Anyway, 1.0 is nearing a state where I'd like to begin hearing benchmarks about it. It's mbox performance should be excellent.
On Mon, Jun 21, 2004 at 08:51:55PM +0300, Timo Sirainen wrote:
On 21.6.2004, at 18:56, Moe Wibble wrote:
- Enabled cache file again. If client asks about something that can be cached for future, it's done. There's currently no smart logic about when not to do it or when to cache more than was asked for future use. Currently nothing is ever deleted from cache. Currently it's disabled if mmap_disable = yes.
...does that mean the cache-file will grow indefinitely?
Yes. Note the "currently" words there :) Will be fixed before 1.0 of course.
Actually I find the current maildir-performance quite amazing when compared to courier or bincimap. The only other imapd that can hold a candle to dovecot (at least according to my little-bit-out-dated and not-so-representative personal benchmarks) appears to be cyrus.
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
Strange... I'd think that rewriting the mbox files would cause a lot more performance issues than shuffling around files in a Maildir. But well, as I mentioned before I'm no friend of mbox anyways and think it should be completely dropped in favor to more ressources spent on Maildir performance/features. I do realize that I'm probably in the minority with that opinion, tho ;)
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needs to resync the whole maildir after each change in mailbox (and sometimes twice).
I haven't tested dovecot in a high load (multiuser) environment yet so I can't say much about the actual load in such a situation. But once the indexes are made (and don't break) what's really left to cause (unjustified) load?
I guess we'll need a IMAP-optimized format sometimes soon.
But please not before maildir support is stable again and shared folders (which I'd claim is a must-have for most corporate deployments) have been implemented. :) <rant> The "proprietary" mailstore-format is the main reason why I'd like to get rid of cyrus. I'll drop it the day that another imapd provides shared folders on regular Maildirs with reasonable performance.. Consequently I'd rather like to see dovecot improve on the indexing/caching- side in order to get most out of Maildir before yet another "prop." format is invented. I do realize that getting the highest performance out of server-side searches may require moving to a prop. format. But for me the drawbacks (uneasy access to the actual mails, probably backup issues/version incompatibilies) outweight the advantages in most cases. Not to mention all the implementation effort that could be spent on smarter Maildir indexing and maybe a separate "search-optimized index" instead ;) </rant>
Again, that's only my opinion. I'd like to hear others on that...
Anyway, 1.0 is nearing a state where I'd like to begin hearing benchmarks about it. It's mbox performance should be excellent.
I'm curious too (more about Maildir performance, tho).
greets
On 21.6.2004, at 21:45, Moe Wibble wrote:
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
Strange... I'd think that rewriting the mbox files would cause a lot more performance issues than shuffling around files in a Maildir.
They probably were using mboxes that had already all the necessay X-UID etc. fields, so rewriting wouldn't need to do more than really required.
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needs to resync the whole maildir after each change in mailbox (and sometimes twice).
I haven't tested dovecot in a high load (multiuser) environment yet so I can't say much about the actual load in such a situation. But once the indexes are made (and don't break) what's really left to cause (unjustified) load?
With maildir the problem is that once it's modified by Dovecot, I can't know if someone else didn't modify it at the same time. So after I change anything it, I'll have to resync the whole maildir again, just in case.
I guess we'll need a IMAP-optimized format sometimes soon.
But please not before maildir support is stable again
I'd probably base it on maildir. Differences would be mostly just: directory's timestamp didn't match the one in index.
- filename = message UID
- new/ directory could exist so existing LDAs can easily add mail
- Dovecot-optimized LDAs would store mails directly into cur/
- if anyone modifies cur/ directory, Dovecot issues a warning when it's noticed but still syncs and fixes it. this fallbacking shouldn't affect performance much, since it would be done only if cur/
- possibly rename the cur/ dir into something else
- possibly add some way to insert new mails into mailbox atomically (mkdir tra/1, put mails there, rename tra/1 tra-done/1 -> after that it's considered as committed and if found by any MUA the mails in it must be moved into cur/)
and shared folders (which I'd claim is a must-have for most corporate deployments) have been implemented. :)
1.0-test sort of tupport shared folders.. If you symlink them manually and create a "dovecot-shared" file with the permissions that should be used for new files. But that's only ugly temporary hack and I'll have to figure out some better way.
I think the proper support is post-1.0 feature.
I do realize that getting the highest performance out of server-side searches may require moving to a prop. format.
Actually I don't think searching can be optimized at all by moving to another format.
But for me the drawbacks (uneasy access to the actual mails, probably backup issues/version incompatibilies) outweight the advantages in most cases. Not to mention all the implementation effort that could be spent on smarter Maildir indexing
Unless the backends share 95% of their code and are compatible in most of the ways.. :)
and maybe a separate "search-optimized index" instead ;)
For SEARCH command, only way to index data in usable way that I know of is the Cyrus squat indexer, but it generates large indexes and it's slow to update, so most people aren't using it.. I'll probably implement it one day though.
Anyway, 1.0 is nearing a state where I'd like to begin hearing benchmarks about it. It's mbox performance should be excellent.
I'm curious too (more about Maildir performance, tho).
Maildir performance should still get somewhat better before 1.0, but mbox has very few optimizations left that I can think of.
Timo Sirainen wrote:
I haven't tested dovecot in a high load (multiuser) environment yet so I can't say much about the actual load in such a situation. But once the indexes are made (and don't break) what's really left to cause (unjustified) load?
With maildir the problem is that once it's modified by Dovecot, I can't know if someone else didn't modify it at the same time. So after I change anything it, I'll have to resync the whole maildir again, just in case.
Might it be possible to have a flag in dovecot's config that would allow for the case when the only change that could happen to a Maildir is the writing of a new file into new/?
In other words the only application other than Dovecot with access to the Maildir is the MTA as it writes new emails into new/? That would enable Dovecot not to have to concern itself with resyncing other directories. This would seem to be the common case when a Maildir is only accessed using IMAP/POP3 in an ISP environment and might provide performance enhancements until a Dovecot LDA is developed.
Or doesn't that make sense? :)
Andrew
On 22.6.2004, at 07:04, Andrew Boothman wrote:
With maildir the problem is that once it's modified by Dovecot, I can't know if someone else didn't modify it at the same time. So after I change anything it, I'll have to resync the whole maildir again, just in case.
Might it be possible to have a flag in dovecot's config that would allow for the case when the only change that could happen to a Maildir is the writing of a new file into new/?
Sure, but that's the beginning on the way for it to be completely different mail format :) Next one would be "keep flag states only in index, don't bother renaming the maildir files", then comes "just keep the filenames named as UID so we don't need to waste memory for maildir filenames". Then it's pretty much what I had in mind for my own mailbox format..
Timo Sirainen wrote:
On 21.6.2004, at 21:45, Moe Wibble wrote:
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
Strange... I'd think that rewriting the mbox files would cause a lot more performance issues than shuffling around files in a Maildir.
They probably were using mboxes that had already all the necessay X-UID etc. fields, so rewriting wouldn't need to do more than really required.
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needs to resync the whole maildir after each change in mailbox (and sometimes twice).
I haven't tested dovecot in a high load (multiuser) environment yet so I can't say much about the actual load in such a situation. But once the indexes are made (and don't break) what's really left to cause (unjustified) load?
With maildir the problem is that once it's modified by Dovecot, I can't know if someone else didn't modify it at the same time. So after I change anything it, I'll have to resync the whole maildir again, just in case.
I get to ask a dumb question: Can you put a filelock on the mail files while you are handling them to ensure that no one else is messing with them? I guess the question is then, if you have N emails in folder, then how do you ensure that the other N-1 emails didn't get messed with, or that there aren't now N+m emails in the maildir...
On 22.6.2004, at 14:07, Tom Allison wrote:
I get to ask a dumb question: Can you put a filelock on the mail files while you are handling them to ensure that no one else is messing with them?
mbox locks the mailbox when reading/writing, maildir doesn't.
I guess the question is then, if you have N emails in folder, then how do you ensure that the other N-1 emails didn't get messed with, or that there aren't now N+m emails in the maildir...
With maildir there's no locks, so mails can come and go anytime. Dovecot handles it well.
Timo Sirainen wrote:
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
IMHO the performace issue and mainly the system load peeks are very important! what's more if cyrus faster than dovecotm, than it's hard to argue for dovecot (since cyrus is more feature rich).
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needs to resync the whole maildir after each change in mailbox (and sometimes twice).
why should have to resync? couldn't be possible to do one atomic rename and index update step without resync? as I wrote about half a year the best solution would be a local delivery agent which can update the index files and spread the load to the arrival time instead of the mail read time.
I guess we'll need a IMAP-optimized format sometimes soon.
than you've to write local delivery agent for many MTAs...
-- Levente "Si vis pacem para bellum!"
Farkas Levente wrote:
Timo Sirainen wrote:
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
IMHO the performace issue and mainly the system load peeks are very important! what's more if cyrus faster than dovecotm, than it's hard to argue for dovecot (since cyrus is more feature rich).
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
But I seem to remember that their indexes had an achilles heal. If you (re)moved an email file via filesystem then the indexes were badly corrupted and there was little you could do with that mail directory again. I don't think that this is proper behaviour for imap servers under a unix environment.
That said, I suspect that cyrus used their indexes as a means of providing some rudimentary search results for a give key and an array of file inodes for the correlating email messages in maildir. This would store the locations in the file inode table, making for a nice speedy access of files. Hence, the removal of a file would corrupt their inode lookup table...
hi,
On 2004-06-21 21:44:13 -0400, Tom Allison wrote:
But I seem to remember that their indexes had an achilles heal. If you (re)moved an email file via filesystem then the indexes were badly corrupted and there was little you could do with that mail directory again. I don't think that this is proper behaviour for imap servers under a unix environment.
thats why normally a user cant access the maildirs directly. so this isnt a case which should happen often. but i agree the failure handling needs some work for that case. :)
thats one of the points i hate about cyrus. you cant access it locally direct. only via imap/pop.
and about the mentioned procmail: you have sieve ... and i like the syntax of it more than the one from procmail. thats why i use maildrop atm.
darix
-- irssi - the client of the smart and beautiful people
http://www.irssi.de/Marcus Rueckert wrote:
and about the mentioned procmail: you have sieve ... and i like the syntax of it more than the one from procmail. thats why i use maildrop atm.
darix
True that about sieve. But I gave up on it as soon as I found out that I couldn't shell out. I run bogofilter as my spam filter and that's only run as a shell application. I guess maildrop can handle this as well, and it might look better than procmail, but sieve definitely cannot do this.
The shell out capability also permits me to test things against email to get a better idea of what might be done to limit spam without losing email. I have never used maildrop, but I understand it can do this just as well. I'm not sure that there is anything that procmail can't do that maildrop can do and visa versa.
On 22.6.2004, at 04:44, Tom Allison wrote:
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
I actually hate procmail. It's code mostly. It's horrible.
But I seem to remember that their indexes had an achilles heal. If you (re)moved an email file via filesystem then the indexes were badly corrupted and there was little you could do with that mail directory again. I don't think that this is proper behaviour for imap servers under a unix environment.
I think it can be fixed by running "cyrusadm recover" or something similiar.
That said, I suspect that cyrus used their indexes as a means of providing some rudimentary search results for a give key and an array of file inodes for the correlating email messages in maildir. This would store the locations in the file inode table, making for a nice speedy access of files. Hence, the removal of a file would corrupt their inode lookup table...
I don't really understand much of that :) If you mean by inode table the real filesystem's inode table, I don't think you can store any custom data there yourself? And removing the file would remove the inode, so no problem there.
Anyway, Cyrus' indexes are currently quite similiar to Dovecot's. It stores more data per mail, but some of it is just bloat and the rest is forcefeeded caching data that client may never use. Cyrus would be able to deal with losing files if it just wanted to.
Implementing Cyrus mail store support for Dovecot might be a fun project, any takers? :)
Timo Sirainen wrote:
On 22.6.2004, at 04:44, Tom Allison wrote:
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
I actually hate procmail. It's code mostly. It's horrible.
what else can we use eg. to put a different folder the dovecot mailing list's mails. which have to work on the server side in order to be able to read by mozilla and webmail to?
-- Levente "Si vis pacem para bellum!"
Farkas Levente wrote:
Timo Sirainen wrote:
On 22.6.2004, at 04:44, Tom Allison wrote:
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
I actually hate procmail. It's code mostly. It's horrible.
what else can we use eg. to put a different folder the dovecot mailing list's mails. which have to work on the server side in order to be able to read by mozilla and webmail to?
my mail is sort by exim with exim filter language and put in directory i want, it is more powerful than procmail
Hervé.
Farkas Levente wrote:
Timo Sirainen wrote:
On 22.6.2004, at 04:44, Tom Allison wrote:
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
I actually hate procmail. It's code mostly. It's horrible.
what else can we use eg. to put a different folder the dovecot mailing list's mails. which have to work on the server side in order to be able to read by mozilla and webmail to?
maildrop, from courier
On 22.6.2004, at 13:43, Farkas Levente wrote:
I actually hate procmail. It's code mostly. It's horrible.
what else can we use eg. to put a different folder the dovecot mailing list's mails. which have to work on the server side in order to be able to read by mozilla and webmail to?
Well, I'm still using procmail myself because I've been too lazy to try out others.. But mvmf looks pretty nice, and since it's author is on this list too maybe he'd like to get it support Dovecot directly :)
On Mon, Jun 21, 2004 at 09:44:13PM -0400, Tom Allison wrote:
Farkas Levente wrote:
Timo Sirainen wrote:
I recently saw some benchmarks (measuring system load) comparing Dovecot mbox, maildir and Cyrus. Dovecot was much slower than I thought, Cyrus was many times faster in most tests. Dovecot with mbox was also much faster than with maildir, even though my 0.99.10 mbox code is pretty bad.
IMHO the performace issue and mainly the system load peeks are very important! what's more if cyrus faster than dovecotm, than it's hard to argue for dovecot (since cyrus is more feature rich).
That last statement is arguable. cyrus-imap has some nice capabilities. But if you use procmail then it's no contest who is going to win! ;)
Agreed. And that sieve stuff is pretty disgusting configwise, too.
But I seem to remember that their indexes had an achilles heal. If you (re)moved an email file via filesystem then the indexes were badly corrupted and there was little you could do with that mail directory again. I don't think that this is proper behaviour for imap servers under a unix environment.
Agreed again. Robustness was obviously not a design goal.
That said, I suspect that cyrus used their indexes as a means of providing some rudimentary search results for a give key and an array of file inodes for the correlating email messages in maildir. This would store the locations in the file inode table, making for a nice speedy access of files. Hence, the removal of a file would corrupt their inode lookup table...
I felt more comfortable w/ my cyrus setup _before_ you told me that. *gulp*
On 22.6.2004, at 01:18, Farkas Levente wrote:
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needs to resync the whole maildir after each change in mailbox (and sometimes twice).
why should have to resync? couldn't be possible to do one atomic rename and index update step without resync?
But to be interoperable with other maildir clients, Dovecot can't know if someone else didn't do other changes within the same second. So it has to resync everything.
as I wrote about half a year the best solution would be a local delivery agent which can update the index files and spread the load to the arrival time instead of the mail read time.
That's also getting near. mbox already updates the mail index when saving mails to it, I'll soon fix it to update cache file as well. I'll do the same for maildir soon too.
I guess we'll need a IMAP-optimized format sometimes soon.
than you've to write local delivery agent for many MTAs...
Not necessarily, it can be maildir-compatible for delivery :)
Timo Sirainen wrote:
On 22.6.2004, at 01:18, Farkas Levente wrote:
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do with maildir format itself, that it needs to rename files when flags change, and Dovecot needsTimo Sirainen tss@iki.fi to resync the whole maildir after each change in mailbox (and sometimes twice).
why should have to resync? couldn't be possible to do one atomic rename and index update step without resync?
But to be interoperable with other maildir clients, Dovecot can't know if someone else didn't do other changes within the same second. So it has to resync everything.
but if this is the real reason there can be a configuration option where the sysadm can state "we don't use other maildir clients". since most of the case that's the situation. and may be some resync can happend when something goes wrong.
as I wrote about half a year the best solution would be a local delivery agent which can update the index files and spread the load to the arrival time instead of the mail read time.
That's also getting near. mbox already updates the mail index when saving mails to it, I'll soon fix it to update cache file as well. I'll do the same for maildir soon too.
there will be a delivery agent which I can set for postfix and procmail to use when store mails?
I guess we'll need a IMAP-optimized format sometimes soon.
than you've to write local delivery agent for many MTAs...
Not necessarily, it can be maildir-compatible for delivery :)
that's would be amazing!
-- Levente "Si vis pacem para bellum!"
On 22.6.2004, at 13:40, Farkas Levente wrote:
But to be interoperable with other maildir clients, Dovecot can't know if someone else didn't do other changes within the same second. So it has to resync everything.
but if this is the real reason there can be a configuration option where the sysadm can state "we don't use other maildir clients". since most of the case that's the situation. and may be some resync can happend when something goes wrong.
Yes, maybe.. Another problem is if indexes can't be used/updated for some reason (eg. user is out of quota) then the other Dovecots are "other maildir clients".
as I wrote about half a year the best solution would be a local delivery agent which can update the index files and spread the load to the arrival time instead of the mail read time. That's also getting near. mbox already updates the mail index when saving mails to it, I'll soon fix it to update cache file as well. I'll do the same for maildir soon too.
there will be a delivery agent which I can set for postfix and procmail to use when store mails?
Yep.
Timo Sirainen tss@iki.fi writes:
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do
Load is the number of processes that are ready to run or running IIRC, hence, iowait contributes to the load without actually doing anything useful besides waiting for the hardware...
-- Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
On 22.6.2004, at 12:01, Matthias Andree wrote:
Timo Sirainen tss@iki.fi writes:
0.99.10 indexes aren't too good, but I still find it a bit strange that Cyrus takes something like 10x less load. I'd think most of it has to do
Load is the number of processes that are ready to run or running IIRC, hence, iowait contributes to the load without actually doing anything useful besides waiting for the hardware...
Yes, but I/O wait is exactly where the problem is. Your mails aren't coming any faster with 0.1% CPU load than with 99% CPU load if I/O is the bottleneck.
Timo Sirainen tss@iki.fi writes:
Yes, but I/O wait is exactly where the problem is. Your mails aren't coming any faster with 0.1% CPU load than with 99% CPU load if I/O is the bottleneck.
I'm still waiting for the day when DJB has to admit that his hardware or OS has cheated on him enabling the write cache defeating f[data]sync() and that made qmail fast. I wonder if he ever did proper testing with unplugging his computer while the queue was full with local deliveries :-P
-- Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
On Mon, Jun 21, 2004 at 05:52:09PM +0300, Timo Sirainen wrote:
Should work again with maildir.
- Some bugfixes to indexes (possibly fixing the still persisting maildir sync errrors?)
Sorry, problemos still present. In addition to what I've seen before...
sp dovecot: IMAP(moe): Maildir /home/moe/Maildir sync: UID < next_uid (312 < 314, file = msg.CDs4:2,)
...I'm now getting these, too:
sp dovecot: IMAP(moe): Corrupted index cache file /home/moe/Maildir/.INBOX/dovecot.index.cache: indexid changed
Over all it feels like the index screws up even more often than with the previous version. That could be just coincidence or wrong perception, tho.
participants (8)
-
Andrew Boothman
-
Farkas Levente
-
Hervé Commowick - NewSports
-
Marcus Rueckert
-
Matthias Andree
-
Moe Wibble
-
Timo Sirainen
-
Tom Allison