Re: Fresh restart? (was: Re: Akonadi database)
Martin Steigerwald - 18.11.17, 11:50:
> > "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.
Okay, I forgot the conclusion:
If you are willing to fix up folder assignments… and your Akonadi database
does not have any items without RID, I think opting for a fresh start is a
… however, what does it buy you?
After pointing your maildir or IMAP resource at the old location Akonadi will
resynchronrize and re-index everything. I doubt that this would take much less
time than the migration process.