FastMail.FM Patchset Updated
simon.matter at invoca.ch
Wed Nov 21 01:40:21 EST 2007
> As usual you can get the patches here:
> I've been busy with Cyrus _again_ - so much for my theory
> that I was taking a break.
> OK - here's what's new.
> Skiplist issues - there were two things that could be found
> in recovery that actually bit us during the whole "restart
> every single store with the new skiplist code" project the
> other day. ADD where the record already existed and DELETE
> where it didn't. The later also had an obnoxious bug where
> it would instead delete _the_alphabetically_NEXT_record_
> silently. Ooops.
> I rolled these two into my bugfix and robustify patches, not
> realising Ken had already applied the previous copies upstream.
> Ken - do you want me to break this out as a separate patch on
> top of the others?
> DelayedDelete of entire users was causing excess copying.
> This fixes it, but the solution is less than ideal and causes
> excess messages about folders not existing during an account
> create. Annoying. I'd like a better fix, but this is enough
> for now. Found this one after fixing...
> This is for upstream. I made a bogus design decision in the
> DelayedDelete code that Ken accepted, and it was causing
> bailouts and all sorts of yuckyness. Made the conditions for
> allowing a folder rename into the DELETED. namespace a lot more
> explicit and correct rather than DELETED.user.foo.TIMESTAMP
> being considered a user's mailbox! The user cleanup script
> no longer causes massive bailouts on sync.
Did you consider this one
http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3006 in the patch above?
>From a quick look it seems both patches conflict, is #3006 obsolete now?
> A little thing to shut up the issue that used to cause segfaults
> and now just causes logging instead. Cache offsets in the .expunge
> file can be bogus for deeper architectural reasons. Rather than
> fix the underlying reasons I just ignore them completely when
> running cyr_expire. At least that way we're not reading bogus
> cache records.
> * http://cyrus.brong.fastmail.fm/patches/cyrus-fastrename-2.3.9.diff
> UPDATED. It turns out it really doesn't matter what YOU can see
> when you're checking if you can use FastRename. It matters if
> there are subfolders at all. Change to passing isadmin true
> and not passing the username to mboxlist_count_inferiors().
> Also need to check if the target path has inferiors to avoid
> log messages and partial move failures that have to back out.
> Much nicer this way. This means fastrename on replicas isn't
> totally broken any more (before, it would never see the subfolders
> because the replication user didn't have ACLs on them and isadmin
> was being set to false explicitly)
> Ken - I'd love to see the deletemode-userfix and skiplist stuff
> go upstream. I know you're not happy with fastrename yet, and
> fair enough - it's an extra risk and if a shutdown happens in
> the middle of the operation things can get very confused! The
> other two patches are not really long-term good for the Cyrus
> codebase so I'd prefer to fix the underlying issues instead :)
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
More information about the Info-cyrus