Does an XFER automatically upgrade the mailbox to the new format? I don't remember having performance problems when I moved users from a v2.3 backend to a new v2.4 backend (a long time ago). Andy On Tue, 21 Apr 2015, Bron Gondwana wrote: > I would wait for 2.5.1, which should be out in a day or so. There were > some XFER bugs in 2.5.0. > > The IO hit will have to be taken regardless, it's just deferred > slightly. The 2.5 backend will work with 2.2 proxies just fine, though > of course most of the new features won't be visible to your clients, > because 2.2 gives a much reduced capability string. > > Longer term, we're looking at a full unified clustering system which might > still include murder or might be totally separate. It's going to be very nice, > but it will only work for 3.0+ servers. > > Bron. > > On Tue, Apr 21, 2015, at 08:07 AM, Michael Sofka wrote: >> On 2015-04-20 17:16, ktm@xxxxxxxx wrote: >>> On Mon, Apr 20, 2015 at 05:11:00PM -0400, Michael D. Sofka wrote: >>>> Under the scenario, would 2.5 work better? >>>> >>>> Mike >>>> >>> Hi Mike, >>> >>> In our case, the unconstrained I/O caused by the mandatory mailbox >>> format conversion on first use would have necessitated a prolonged >>> service outage to prevent overloading the system. 2.5 will allow you >>> to schedule your conversions while the system is functional. This >>> may not be a concern for you. >> >> >> Hum, it might.... This would drive up the load on the 2.4 system as >> I'm moving mailboxes? >> >> This project is driven entirely by the state of the SAN disks. They >> are either old with controller errors, or expensive to keep on >> service, or needed elsewhere in a chain of updates. Plan B is to >> clone the existing >> 2.3 server, but if I can get a new OS and application image in the >> process, I will be a happy camper. But even doing that is exceeding >> my mandate. >> >> But if a 2.5 image will work with 2.2 front-end proxies, the deferred >> conversion is worth considering. I do anticipate the moves being off- >> hours, but even off-hours is busy. >> >> Mike >> >> >> -- >> Michael D. Sofka sofkam@xxxxxxx C&MT Sr. Systems >> Programmer, Email, TeX, Epistemology Rensselaer Polytechnic >> Institute, Troy, NY. http://www.rpi.edu/~sofkam/ >> >> ---- >> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: >> http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: >> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > > > -- > Bron Gondwana > brong@xxxxxxxxxxx > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
