Fresh restart? (was: Re: Akonadi database)
Hello Frank.
Frank Mehnert - 17.11.17, 16:26:
> On Freitag, 17. November 2017 16:11:39 CET Martin Steigerwald wrote:
> > Martin Steigerwald - 17.11.17, 11:27:
[…]
> Did you actually see my other mail? Again, my question was not about having
> a DB or not, it was about whether it's possible to take a shortcut during
> KDE upgrade or not and about possible consequences. And it was definitely
> not meant to start another discussion.
>
> I'm still interested in the answer to my question.
Okay, here goes your text as you send me privately. I really did not see it on
the mailinglist.
> "sorry, I didn't get my message across. I didn't want to argue about
> having a database or not having a database. What I wanted to ask is
> it would be possible to "reset" the database as this might be faster
> than upgrading + optimizing it several times. I mean, remove it and
> let Akonadi rebuild it again."
Yes, Frank, that is possible… and it sounds tempting… however…
KMail stores folder assignments in its configuration files as ids of the
database entry. That means that after a database wipe all and any folder
assignments may point to the wrong folders. This includes:
- the inbox, sent, trash and so on folders set in the identity and the POP3/
IMAP resource
- all folders of all local filters, if you use POP3 with local maildirs and
have a lot of filters you have to recheck all of these.
Additionally: Akonadi is not just a read-cache, it is also a limited write-
cache. It may happen that an IMAP connection is lost as Akonadi IMAP resource
wants to put a mail there. It keeps it locally then. It may happen that an out
of space error occurs while Akonadi maildir resource tries to stuff a mail
into the maildir. Most important in this is this:
Akonadi, as to what I know and have been told by Daniel Vrátil, never *ever*
tries to stuff the mail again into the backend store. So they sit in the
database, and *just* in the database. *Forever*.
Those are the items without RID (remote identifier). akonadictl fsck will tell
you whether you have some of them.
I do have some of them. I never investigated whether they are really important
to me, and as far as I understand I would have to look up every single item in
the database to find out.
In my eyes, and Daniel principally agrees with that, this is a bug that needs
to be addressed. I think it would be good not to store any pending mails that
could not yet stored into the backend store, into the database. But if they
are, there needs to be a way to trigger a replay of these items and to get
useful error message and a list of what they contain.
This also has been addressed on kdepim-users. I strongly suggest anyone who is
working with KDEPIM on a daily basis to subscribe there. Unfortunately even
akonadictl fsck can not fix any of this, i.e. initiate a replay of these items
to backend storage. I still have that akonadictl fsck mail from me on kdepim-
users where Daniel replied to in detail in mind. I did not return to it as I
had outdated KDEPIM 16.04 back then, but I may, cause:
What use is a fsck, that can´t fix the things it reports?
Thanks,
--
Martin
Reply to: