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

[Milian Wolff]

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

In my cache folder, that would produce the following:

#entries | prefix
  11080 10
   2032 11
    567 12
   1768 13
   5444 14
   1066 15
    520 16
   1823 17
   2159 18
   2722 19
   2195 20
   2502 21
   2042 22
   2271 23
   2108 24
   2274 25
   2161 26
   2317 27
   2379 28
   2688 29
   1827 30
   1303 31
    978 32
   1526 33
   1702 34
   1553 35
   1759 36
   1284 37
   1903 38
   1935 39
   1540 40
   1583 41
   1521 42
   2322 43
   2548 44
   2508 45
   2303 46
   2266 47
   2793 48
   2610 49
   5142 50
   3140 51
   2586 52
   2075 53
   2513 54
   1950 55
   2310 56
   2345 57
   2458 58
   1900 59
   2139 60
   1923 61
   1984 62
   1727 63
   1722 64
   1687 65
     51 66
   1425 67
   1801 68
   1667 69
   1644 70
   1569 71
   1722 72
   1118 73
   2913 74
   1983 75
   1301 76
   1683 77
   1637 78
   1974 79
   1369 80
   2143 81
   1764 82
   1818 83
   1743 84
   1973 85
   1876 86
   1901 87
   2582 88
   1923 89
   2508 90
   2383 91
   3842 92
   2564 93
   2898 94
   2194 95
   2015 96
   2199 97
   2498 98
   2549 99

of course, this could be further improved by using the last two integers of 
the ID instead of the first (to prevent e.g. all files of ID 10... to be moved 
into the 10 bucket, as seen above). It's still trivial to do the lookup by ID 
then, definitely not much slower than before.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de