Re: fadvise WILLNEED for tokyocabinet header cache
Hi,
* Kyle Wheeler wrote:
> What about using the mtime/ctime timestamp on the cur directory to
> determine whether it's changed since the last time it was read? All
> flag changes, message deliveries, etc. *should* update the
> directory's inode atime/ctime. That way you don't need a
> configuration knob, and it should be a generalized optimization that
> applies to all situations. It'd add a stat call to the opening
> process, and you'd have to store the last-known-mtime in the cache,
> but...
We do support storing arbitrary values in the cache, so that'd
work. Some time ago I've also toyed with dumping the cache. As a partial
result I know that the 3 major backends support key traversal. So that'd
work, too. The problem is when you have only one hcache for all folders
because then we're CPU-bound as we need to check each key if it belongs
to the mailbox we currently open. But for one-db-per-folder we can even
drop that check I guess and just can iterate over the keys.
So the only real issue is when the FS isn't accurate about the times for
the directory.
> for enormous cached maildirs it'd provide a big win (for
> efficiency, you'd probably want an update-able cache, rather than an
> append-only cache, but that's true in general).
The cache is updateable for some time now (weeks I think).
Rocco