Re: Cyrus aggregate compatibility.

2015-04-22 Thread Ciro Iriarte
I've seen you talking about the new clustering approach, can you elaborate a little (maybe in a separate topic/mail)?. Given the state of distributed storage solution, shouldn't that be considered?. For example Nutanix adds capacity with each new node and the interface is just NFS. Wouldn't that m

Re: Cyrus aggregate compatibility.

2015-04-20 Thread 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 m

Re: Cyrus aggregate compatibility.

2015-04-20 Thread Bron Gondwana
>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 mainta

Re: Cyrus aggregate compatibility.

2015-04-20 Thread Andrew Morgan
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 i

Re: Cyrus aggregate compatibility.

2015-04-20 Thread Bron Gondwana
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 clien

Re: Cyrus aggregate compatibility.

2015-04-20 Thread Michael Sofka
On 2015-04-20 17:16, k...@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

Re: Cyrus aggregate compatibility.

2015-04-20 Thread k...@rice.edu
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 overl

Re: Cyrus aggregate compatibility.

2015-04-20 Thread Michael D. Sofka
Under the scenario, would 2.5 work better? Mike On 04/20/2015 04:45 PM, k...@rice.edu wrote: > On Mon, Apr 20, 2015 at 04:23:07PM -0400, Michael D. Sofka wrote: >> We currently have: >> >> Cyrus Front-End servers running 2.2.12 >> Cyrus Back-End running 2.3.16 >> >> I have built a

Re: Cyrus aggregate compatibility.

2015-04-20 Thread k...@rice.edu
On Mon, Apr 20, 2015 at 04:23:07PM -0400, Michael D. Sofka wrote: > We currently have: > >Cyrus Front-End servers running 2.2.12 >Cyrus Back-End running 2.3.16 > > I have built a new back-end server running 2.4.17. > > > I plan on adding the new, 2.4 server, to the aggregate, an

Cyrus aggregate compatibility.

2015-04-20 Thread Michael D. Sofka
We currently have: Cyrus Front-End servers running 2.2.12 Cyrus Back-End running 2.3.16 I have built a new back-end server running 2.4.17. I plan on adding the new, 2.4 server, to the aggregate, and move all the mailboxes. I would rather not upgrade the front-end servers, since