On Monday, October 31, 2011 11:36 PM, "Martin Kraus" <martin.kraus@xxxxxxxxxxx> wrote:
> I just want to move mailboxes to a different filesystem. replication is a bit
> of an overkill for a onetime move. if the renamemailbox copies everything and
> doesn't screw the mailbox in the process then it's ok for what I need.
No, no - not actually replication. Just the logic. For this it would be:
Pass 1a: Lock the mailbox and take a copy onto the new partition, then release all
locks except the read NAMELOCK with stops file deletion.
Pass 1b: open the copy of the index, and for every UID listed, copy the file to
the destination partition.
Pass 2a: Read the source mailbox and destination mailbox, make a list of new files
to copy, then release the lock again.
Pass 2b: Copy the new files across.
Pass 3a: Lock the source mailbox and copy any remaining files WHILE STILL UNDER THE
LOCK. Also, copy the index file now (potentially also the cache file. You
can copy the squat file later). Also, update the mailboxes.db record with
the new partition, THEN release the lock.
This should lead to three very short locks, barely noticable, rather than one long
outage when copying a bit mailbox.
(why three passes rather than 2? The first pass could take hours with a bit mailbox,
I recently moved a 200Gb mailbox, and so the caches will all be stale by the end.
The second pass is largely to re-heat the caches, and also because a lot of new email
could have arrived in that time)
You could make 'Pass 2' just keep repeating until the number of new messages fell
below some arbitrarily small limit, if you cared.
Anyway - that's the algorithm I was talking about. It's nicer than locking during
the slow bits, and it's part of the point of namelocks.
Bron.
--
Bron Gondwana
brong@xxxxxxxxxxx
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
