[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