[Kde-pim] Akonadi(Next): Thoughts on caching

Martin Steigerwald Martin at lichtvoll.de
Wed Jan 21 13:12:19 GMT 2015


Am Mittwoch, 21. Januar 2015, 14:00:48 schrieben Sie:
> On Wednesday 21 January 2015 11:46:07 Martin Steigerwald wrote:
> > Hi!
> > 
> > Considering:
> > 
> > [Akonadi] [Bug 338402] File system cache is inneficient : too many file
> > per
> > directory
> > 
> > Bug 332013 - NFS with NetApp FAS: please split payload files in
> > file_db_data into several directories to avoid reaching maxdirsize limit
> > on Ontap / WAFL filesystem
> 
> This should actually be trivial to fix. One just needs to add N levels of
> directories inbetween. I.e. now the naming scheme is
> 
> $path/$id_$suffix
> e.g.:
> $path/304118_r0
> $path/750546_r1
> 
> instead, it could do something like git does:
> 
> $path/$id[0]$id[1]/$id[2:]_$suffix
> 
> e.g.:
> $path/30/4118_r0
> $path/75/0546_r1

Yeah. Thats for the amount of files in one directory.

But honestly I still think:

Akonadi caches too much for online IMAP accounts:

500000+ files, together about 7 GiB with an IMAP account that did not have 
download mails for offline usage checked.

I still fail to see the benefit for that.

Baloo or Akonadi based fulltext indexer needs to see each mail just once. So 
caching makes no sense for that case.

And I as a user? Honestly, even after I took my photo reading course: No way 
:).

> In my cache folder, that would produce the following:
> 
> #entries | prefix
>   11080 10
>    2032 11
>     567 12

Looks quite well distributed.

And probably would not even require a migration. As new files could be create 
with the new scheme while the old are still references with their old 
location.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list