On Thu, Jun 12, 2014 at 10:47 AM, Pranith Kumar Karampuri < pkara...@redhat.com> wrote:
> > On 06/12/2014 11:16 PM, Anand Avati wrote: > > > > > On Thu, Jun 12, 2014 at 10:39 AM, Ravishankar N <ravishan...@redhat.com> > wrote: > >> On 06/12/2014 08:19 PM, Justin Clift wrote: >> >>> On 12/06/2014, at 2:22 PM, Ravishankar N wrote: >>> <snip> >>> >>>> But we will still hit the problem when rolling upgrade is performed >>>> from 3.4 to 3.5, unless the clients are also upgraded to 3.5 >>>> >>> >>> Could we introduce a client side patch into (say) 3.4.5 that helps >>> with this? >>> >> But the client side patch is needed only if Avati's server (posix) fix >> is present. And that is present only in 3.5 and not 3.4 . > > > > The client can actually be fixed to be compatible with both old and new > servers. We can change the errno from ESTALE to ENOENT before doing the > GFID mismatch check in client_lookup_cbk. > > But this will require a two hop upgrade. Is that normal/acceptable? > One hop is always better than two hops. But at least we have a way out. It is not at all unreasonable to have clients be of a minimum version for rolling upgrades to work (upgrade still works no matter what the client versions are if they are doing read-only access).
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
