Hello Tamo,
> Even when hcache is enabled, we want to enable inode_sorting in some
> cases, doesn't we?
In some rare border cases maybe. But in general now. The bordercases
which come in my mind:
> e.g. cachefile lost,
But this is the general idea of hcache: Initial caching takes time,
consecutive access is fast. Also note that inode sorting has O(log(n))
in processing power (if my coworker remembers the cost of merge sort
right). So the bigger your mailbox is the lesser is the performance gain of
inode sorting.
> many new messages,
There must be 90 % new messages and that on every open. So you can
turn-off hcache at all because in such cases it just begs on your CPU.
Also see below.
> or cache_verify set
This option shouldn't be used. It's just there to safe users from their
own stupidity (see debian bugtracking system[1]). The regular user should
disable this. Maybe I should turn it by default off.
> Do you have any opinion on my patch to switch on/off the sorting?
I saw your patch before and I like the way of turning inode sorting on
and off during runtime. So you can use it in a folder-hook to enable the
sorting were it actually gains performance: A mailbox which has a huge
incomming count but the messages get deleted instead after reading:
But remember the inode sorting patch only helps on a few filesystems.
I have some bordercases myself:
folder-hook . 'set header_cache="/tmp/sithglan-hcache/"'
folder-hook 'Maildir$' 'set header_cache=""'
folder-hook '.lists.cip.system$' 'set header_cache=""'
folder-hook '.lists.cip.problems$' 'set header_cache=""'
But my general point of view stays the same:
Inode sorting doesn't make sense with enabled hcache.
Greetings,
Thomas
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199052