Re: akonadi/KDE PIM backup/restore
Martin Steigerwald <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <1722740.uGfcAFU57P@merkaba> |
Am Freitag, 14. Oktober 2016, 10:20:01 CEST schrieb René J.V. Bertin: > On Friday October 14 2016 08:36:56 Daniel Vrátil wrote: […] > >I would argue that except for the search index, you want to preserve > >everything (including the massive file_db_data), see below. > > That's OK. > > file_db_data is massive indeed, though for me more in number of files (over > 5000) than bytes-on-disk (59Mb with ZFS lz4 compression which works nicely > on text). > > Still, would you incur a big performance penalty using libzip or some such > (leveldb?) to store all those files in an indexed, compressed archive. A > massive directory containing (tens of) thousands of files isn't exactly > efficient (and probably even more massive in terms of actual disk (sector) > usage). I should probably spin this off to a separate thread. Actually I don´t get some of the sizes in my setups. Private mail account with more than 2000000 mails: […]~/.local/share/akonadi> LANG=C du -sch db_data file_db_data search_db 3.7G db_data 176M file_db_data 3.6G search_db 7.5G total […]~/.local/share/akonadi> find file_db_data -type f | wc -l 19639 Exchange IMAP work account with fewer mails than the private one: […]~/.local/share/akonadi> LANG=C du -sch db_data file_db_data search_db 8,7G db_data 3,6G file_db_data 1,3G search_db 14G total […]~/.local/share/akonadi> find file_db_data -type f | wc -l 29767 […]~/.local/share> du -sh local-mail 24G local-mail […]~/.local/share> find local-mail -type f | wc -l 2108033 Yes, this is no joke :) 14 GiB in total for managing *metadata* for my IMAP account. *Seriously*? Thats easily half a size or more of the whole account. Exchange reports I think 27 GB for the account, but I don´t really believe it. And yes, I have run a akonadictl fsck ; akonadictl vacuum on it recently. And search_db may not even complete, as I nuked it after it filled my /home. I even touched a file "search_db" to avoid Akonadi Search recreating it, but it seems it nuked my file. So one bet is: Akonadi Search tries to build search db again and thus Akonadi receives all the mails through IMAP and *caches* then. Can we have Akonadi *not* cache any mails that Akonadi Search requests – it is utterly pointless to cache them? And I really would like to tell Akonadi how long it should retain items in cache and I would tell it: Forget after 2 weeks already. Exchange IMAP is bad, but not that bad that I need a local copy of everything (especially when not telling it to do disconnected IMAP). Thanks -- Martin