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 viable option… … 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. Thanks, -- Martin