<div dir="ltr">I too would like to know about this.<div><br></div><div>I also tried this process on my 3.2.7 cluster and reported my findings here:</div><div><a href="http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/">http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/</a><br>

</div><div><br></div><div>No reply as of yet...</div><div><br></div><div>Not wanting to sound negative, but I do find there&#39;s little support from the Gluster sites/community on issues such as this. Especially compared to other projects I&#39;ve seen. It&#39;s not very reassuring for a film-system in which we&#39;re supposed to trust with our precious data.</div>

<div><br></div><div>For this reason - we are looking to migrate away from Gluster after using it for 3+ years.  It&#39;s a shame - and I was a believer (still think it&#39;s a great idea) - but we can&#39;t afford to carry on groping around in the dark (with sparse documentation, obscure error messages &amp; a low-bandwidth community) any more. :/</div>

<div><br></div><div>Still interested to hear if / how we can upgrade by hand (if need be). Would certainly help me in the interim - might even change my mind (not having seen 3.4 in action)..  :)</div><div> </div><div><br>

</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 February 2014 13:22, Dmitry Kopelevich <span dir="ltr">&lt;<a href="mailto:dkopelevich@che.ufl.edu" target="_blank">dkopelevich@che.ufl.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>I would like to follow up on my
      question regarding an upgrade from 3.2.6 to 3.4.2. <br>
      Can anybody tell me whether I&#39;m doing something completely wrong?
      Am I trying to skip too many versions of gluster in my upgrade? Is
      CentOS 5 too old for this?<br>
      <br>
      Thanks,<br>
      <br>
      Dmitry  <br><div><div class="h5">
      <br>
      On 2/18/2014 2:51 PM, Dmitry Kopelevich wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      
      I am attempting to upgrade my GlusterFS from 3.2.6 to 3.4.2 using
      the instructions posted at <a href="http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3" target="_blank">http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3</a>.
      These guidelines are for an upgrade to 3.3 but it is stated at <a href="http://vbellur.wordpress.com/2013/07/15/upgrading-to-glusterfs-3-4" target="_blank">http://vbellur.wordpress.com/2013/07/15/upgrading-to-glusterfs-3-4</a>
      that they can also be used to upgrade to 3.4.0. So I was hoping
      that they would also work with an upgrade to 3.4.2. <br>
      <br>
      I&#39;m running CentOS 5 and installed the following rpms on the
      gluster servers:<br>
      <br>
      <tt>glusterfs-libs-3.4.2-1.el5.x86_64.rpm</tt><tt><br>
      </tt><tt> glusterfs-3.4.2-1.el5.x86_64.rpm</tt><tt><br>
      </tt><tt> glusterfs-fuse-3.4.2-1.el5.x86_64.rpm</tt><tt><br>
      </tt><tt> glusterfs-cli-3.4.2-1.el5.x86_64.rpm</tt><tt><br>
      </tt><tt> glusterfs-server-3.4.2-1.el5.x86_64.rpm </tt><tt><br>
      </tt><tt> glusterfs-rdma-3.4.2-1.el5.x86_64.rpm</tt><tt><br>
      </tt><tt> glusterfs-geo-replication-3.4.2-1.el5.x86_64.rpm</tt><br>
      <br>
      According to the installation guidelines, installation from rpms
      should automatically copy the files from /etc/glusterd to
      /var/lib/glusterd. This didn&#39;t happen for me -- the directory
      /var/lib/glusterd contained only empty subdirectories. But the
      content of /etc/glusterd directory has moved to
      /etc/glusterd/glusterd. <br>
      <br>
      So, I decided to manually copy files from /etc/glusterd/glusterd
      to /var/lib/glusterd and follow step 5 of the installation
      guidelines (which was supposed to be skipped when installing from
      rpms):<br>
      <br>
      <tt>glusterd --xlator-option *.upgrade=on -N</tt><tt><br>
        <br>
      </tt>This didn&#39;t work (error message: glusterd: No match)<font face="sans-serif"><tt><br>
          <br>
          <font face="sans-serif">Then I t<tt><font face="sans-serif">ried</font></tt><tt><font face="sans-serif"> specifyin<tt><font face="sans-serif">g
                    explicitly the name of my volu<tt><font face="sans-serif">me:</font></tt></font></tt></font></tt></font><br>
          <br>
        </tt><tt>glusterd --xlator-option </tt></font><tt><tt>&lt;volume&gt;</tt></tt><font face="sans-serif"><tt>.upgrade=on -N</tt></font><tt><br>
      </tt><tt><br>
      </tt>This lead to the following messages in file
      etc-glusterfs-glusterd.vol.log:<br>
      <br>
      <tt>[</tt><tt>2014-02-18 17:22:27.146449] I [glusterd.c:961:init]
        0-management: Using /var/lib/glusterd as working directory</tt><tt><br>
      </tt><tt>[2014-02-18 17:22:27.149097] I
        [socket.c:3480:socket_init] 0-socket.management: SSL support is
        NOT enabled </tt><tt><br>
      </tt><tt>[2014-02-18 17:22:27.149126] I
        [socket.c:3495:socket_init] 0-socket.management: using system
        polling thread</tt><tt><br>
      </tt><tt>[2014-02-18 17:22:29.282665] I
        [glusterd-store.c:1339:glusterd_restore_op_version] 0-glusterd:
        retrieved op-version: 1</tt><tt><br>
      </tt><tt>[2014-02-18 17:22:29.283478] E
        [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-:
        Unknown key: brick-0</tt><tt><br>
      </tt><tt>[2014-02-18 17:22:29.283513] E
        [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-:
        Unknown key: brick-1</tt><tt><br>
      </tt><tt>[2014-02-18 17:22:29.283534] E
        [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-:
        Unknown key: brick-2</tt><br>
      ... <br>
      and so on for all other bricks.<br>
      <br>
      After that, files nfs.log, glustershd.log, and
      etc-glusterfs-glusterd.vol.log get filled with a large number of
      warning messages and nothing else seems to happen. The following
      messages appear to be relevant:<br>
      <br>
      - Files nfs.log, glustershd.log:<br>
      <br>
      <tt>2014-02-18 15:58:01.889847] W
        [rdma.c:1079:gf_rdma_cm_event_handler] 0-data-volume-client-2:
        cma event RDMA_CM_EVENT_ADDR_ERROR, error -2 (me: peer:)<br>
      </tt><br>
      (the name of my volume is data-volume and its transport type is
      RDMA)<br>
      <br>
      - File etc-glusterfs-glusterd.vol.log<br>
      <br>
      <tt>[2014-02-18 17:22:33.322565] W [socket.c:514:__socket_rwv]
        0-management: readv failed (No data available)</tt><br>
      <br>
      Also, for some reason the time stamps in the log files are
      incorrect.<br>
      <br>
      Any suggestions for fixing this would be greatly appreciated.<br>
      <br>
      Thanks,<br>
      <br>
      Dmitry<br>
      <pre cols="72">-- 
Dmitry Kopelevich
Associate Professor
Chemical Engineering Department
University of Florida
Gainesville, FL 32611

Phone:   (352)-392-4422
Fax:     (352)-392-9513
E-mail:  <a href="mailto:dkopelevich@che.ufl.edu" target="_blank">dkopelevich@che.ufl.edu</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br></blockquote></div><br></div>