<!DOCTYPE html>
<html>
<head>
<title></title>
<style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div style="font-family:Arial;">Followup on this - I pushed a commit to master which included a few comments highlighting places in the code where changes would help.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">ellie is going to work on the changes, to be reviewed by Partha.   None of these changes make any alterations to the replication protocol, all they change is:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">1) which mailboxes are batched together when multiple mailboxes are being checked at once (SYNC GET MAILBOXES)<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">2) what gets done in interesting cases (e.g. when a folder named in the sync log is present on the replica but not on the master)<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Cheers,<br></div>
<div style="font-family:Arial;"><br>Bron.<br></div>
<div><br></div>
<div><br></div>
<div>On Mon, 26 Feb 2018, at 18:28, Bron Gondwana wrote:<br></div>
<blockquote type="cite"><div style="font-family:Arial;">Hey - here's me posting something to the public list instead of internal FastMail slack.  We've been really bad at making our random ruminations public, sorry.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Tomorrow (Tues 27th) 2pm Melbourne time, I'm going to be meeting with ellie and maybe Partha in the Melbourne office with a whiteboard and a screen to flesh out some ideas for things we can do to fix some of the issues that came up after a recent machine failure event at FastMail.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">In particular, sync sheer is a very real problem.  The core issue is something like this, either:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">a)<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">sync_log MAILBOX A<br></div>
<div style="font-family:Arial;">sync_log MAILBOX A<br></div>
<div style="font-family:Arial;">sync_log MAILBOX B<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Underlying cause - something happened on mailbox A, then mailbox A was renamed to B.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Result - if there is a log split between those two lines, the sync_client first sees just MAILBOX A, and so it just processes that one mailbox.  It sees:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">local: MAILBOX A IMAP_MAILBOX_NONEXISTENT<br></div>
<div style="font-family:Arial;">remote: MAILBOX A exists<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">so it issues an UNMAILBOX A, then processes the second file.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">In the second file, it gets:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">local: MAILBOX A IMAP_MAILBOX_NONEXISTENT<br></div>
<div style="font-family:Arial;">local: MAILBOX B exists<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">remote: MAILBOX A IMAP_MAILBOX_NONEXISTENT<br></div>
<div style="font-family:Arial;">remote: MAILBOX B IMAP_MAILBOX_NONEXISTENT<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">So it creates B and copies all the messages again.  This is correct, but it's both inefficient and creates a gap where the replica doesn't have the messages at all.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">b) there are over 1000 mailboxes, and the log file got deduplicated and then run in sets, and we had this:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">sync_log MAILBOX Z<br></div>
<div style="font-family:Arial;">sync_log MAILBOX B<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">(for a rename of Z to B)<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">local: MAILBOX B exists<br></div>
<div style="font-family:Arial;">remote: MAILBOX B IMAP_MAILBOX_NONEXISTENT<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">We upload the entire mailbox.  Later we see both mailbox Z and mailbox B, and due to uniqueid duplication and the existence of mailbox B, we forget about mailbox Z entirely - leaving a duplicate on the server.  Until a recent change, this led to real mess when running reconstruct caused mailbox Z to get a new uniqueid, just on the end where the reconstruct was run.  Run it on both ends later, you could wind up with different uniqueids, and replication bails on that because it's confused!<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">The long term solution to all this is to replicate by uniqueid, and replicate the name history entirely for each folder such that you can calculate the delta and converge on the latest name for the folder in split brain.  But for now, maybe we can make this safer.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">My initial thought is something like: if the folder exists at one end, but not at the other (either way) do a full user sync.<br></div>
</div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Also, if splitting > 1000 folders in sync_client, make sure we keep all the folder for a user in a single batch, so don't split batches inside a user.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">We may be able to use the tombstone records we've been storing for a while to decide whether the lack of a folder is "it used to exist, but it doesn't any more" or "it never existed here" - handy for figuring out split brain recovery.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Added complications: what about cross-user renames?  What about renaming users entirely?<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">I know some of what Ken has been working on will also possibly interact with this, so we're looking for some simple heuristic changes that can make everyday situations safer while we wait for the real solution.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Bron.<br></div>
<div style="font-family:Arial;"><br></div>
<div><div>--<br></div>
<div>  Bron Gondwana, CEO, FastMail Pty Ltd<br></div>
<div>  brong@fastmailteam.com<br></div>
<div><br></div>
</div>
<div style="font-family:Arial;"><br></div>
</blockquote><div style="font-family:Arial;"><br></div>
<div id="sig56629417"><div class="signature">--<br></div>
<div class="signature">  Bron Gondwana, CEO, FastMail Pty Ltd<br></div>
<div class="signature">  brong@fastmailteam.com<br></div>
<div class="signature"><br></div>
</div>
<div style="font-family:Arial;"><br></div>
</body>
</html>