Mike, this means that the I/O hit from "upgrading" will happen at the time you XFER the mailbox. That's good because you can control the I/O by spreading out your XFERs, if it's even a problem. I moved a lot of mailboxes (30,000+) without really noticing a problem. I did try to perform the moves during less busy times of the day though. Andy On Tue, 21 Apr 2015, Bron Gondwana wrote: > From 2.3 to 2.4 upgraded automatically. > > From x to 2.5 doesn't upgrade automatically at the moment. You have to run > reconstruct -V max on the folder afterwards. > > Maybe for the XFER case we should upgrade automatically... I'll talk to Ellie > about that when she gets in today. She's the 2.5 maintainer now. > > Bron . > > On Tue, Apr 21, 2015, at 08:51 AM, Andrew Morgan wrote: >> 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 >>> > > > -- > 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
