Cyrus aggregate compatibility.

[Andrew Morgan]

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 at rice.edu 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 at rpi.edu 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 at fastmail.fm
>>> ----
>>> 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 at fastmail.fm
>