thoughts about conversation db and cyrus [faild to rename deleted mailbox, or how conversation db sucks again]
Michael Menge
michael.menge at zdv.uni-tuebingen.de
Mon Mar 4 10:17:28 EST 2019
Hi Ellie and Bron,
first thank you for your ideas for the workaround and for opening the issue.
I have to apologize about the original subject, but I was a bit
frustrated that
I have encountered again a problem with the conversation db.
As I have discovered jet another, not jet reported problem with
conversation db
(I am unsure if it's a problem with the conversation db or if only
shows an other
problem some where else), I have decided to deactivate the conversation db for
the moment.
I think I should elaborate the general problem I have with this
feature and the
cyrus development as i have observed it.
I am an experienced linux and cyrus administrator. I am not an
software developer,
or programmer, but I understand enough about programming to fix small problems
and narrow down problems.
Cyrus code quality has grown in the last 14 years since i first set up
our first
cyrus imap (2.3) server. Especially since Fastmail dedicated personal for the
cyrus project. But also automatic testing and other design decisions helped to
bring the project a big step forward.
I know we have a complex setup (murder, replication, meta- and archive
partition,
delayed delete, delayed expunge) so that we use combinations of
features that are not
that common. So fare we are happy with our cyrus setup.
We did not encounter any data loss, and where able to fix most
problems in short time.
The system is very stable and expect for the slow search can't
complain about the performance.
So thanks again to the devs for the work and also for the community
the help I received
in the last 14 years.
I like new features, but I have always to balance the advantages of
these new features
with the impact on stability, performance and administration overhead.
In that regard I
tend to exercise caution.
While testing cyrus 3.0, on one hand neither conversation db nor
sphinx or xapian search
engines looked particular interesting, as I had no need to improve
search speed in
cyrus 2.4 with squatter ("If it isn't broken don't fix it"). On the
other hand i didn't
have time to rigorous test these features, so I decided not to use
them as new feature
have a tendency to contain more new bugs.
After upgrading the production system to cyrus 3.0 I discovered that
search was slow with
squatter, conversation db did more than the documentation suggested
that it does.
I don't know if it was intended that conversation db was required for
squatter to work
or if it broke by one change to support multiple search engines but
the requirement
was surprising. I did try to find the commit that did break the
squatter search but
failed, as was unable to compile most commits git bisect suggested.
The problems I encountered with conversation db, confirmed my initial
caution not to enable
conversation db without testing. But it would be unfair to blame only
the implementation of
conversation db.
One problem was caused by "reconstruct -V max" not upgrading all
mailboxes, which i did
miss in the logs. It would be nice if ctl_conversationsdb would check
mailbox version
before creating a huge conversation db file in an endless loop.
The problem with "IOERROR: conversations_audit on load:" and "IOERROR:
conversations_audit on store:"
is still a mystery to so it is unclear if it is really a bug in the
conversation db of if it shows
an other problem with my installation.
The same is with the new problem i had no time to report jet. Deleting
users i see the following error
popping up for some accounts.
"Fatal error: Internal error: assertion failed: imap/conversations.c:
2205: !status.exists"
But breaking an common use case of an other feature like "delete_mode:
delayed" is
an other case. This should have been fixed before it was released in
the stable
cyrus version. At least a WARNING in the documentation is required.
I would like to help to improve the documentation, but there are some
questions that need to be answered:
1. Which search engines and combinations are currently supported?
Is a stand alone squatter still supported?
2. What are to pros and cons for the supported search engines?
3. Should, or to which extend should, the search engines work without
conversations db?
Or is enabling the conversations db a new requirement for some/all
search engines?
4. Is the conversations db murder aware? And how do shared folders
(one user shared one
of his folders with other users) on the same server/cross server
affect search results and performances
5. What is stored in the conversations db?
https://www.cyrusimap.org/dev/imap/concepts/deployment/databases.html#conversations-userid-conversations
is incomplete as conversations db also contains hashes of mime parts.
6. Which Information is affected by conversations_expire_days
TLDR; I like cyrus, but there is some work to do regarding to
conversation db and search engines,
in the field of documentation, code testing and feature interaction
--------------------------------------------------------------------------------
M.Menge Tel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
michael.menge at zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
More information about the Info-cyrus
mailing list