Lazy opening of cyrus.cache file
brong at fastmail.fm
Mon Mar 23 16:51:37 EDT 2009
On Mon, Mar 23, 2009 at 02:31:53PM +0000, David Carter wrote:
> On Tue, 24 Mar 2009, Bron Gondwana wrote:
>> Only very lightly tested... but hey.
>> Don't open the cyrus.cache file unless you need to,
>> handy for those people running with small fast meta
>> partitions and slow big partitions with the
>> cyrus.cache on them :)
> Curiously I was having similar thoughts after laying my grubby paws on a
> pair of Intel X25e SSDs last week.
So I heard in "the other place", which is what prompted me to
visit this, since I already had the patch which does the heavy
> What are you doing about the generation numbers in the cyrus.index and
> cyrus.cache file?
Failing to open it. My eventual solution is going to involve rewriting
the bloody thing, but that means abstracting out the cache writing bits
of reconstruct so that I can call a "fix cache file" command if
corruption is found rather than just syslogging it and expecting someone
else to come and run the reconstruct.
> There is a fairly elaborate dance in mailbox_open_index() to make sure
> that the correct pair of files are open in the face of mailbox_expunge()
> renaming two files in rapid succession in immediate or cleanup mode.
See, mailbox_expunge SHOULD be keeping an exclusive lock on
cyrus.header, meaning everybody else waits until it's stable. The only
place that needs anything like an elaborate dance should be
cyrus.header, because there's nothing that can be locked before it.
More information about the Cyrus-devel