<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
just checked my own mail archive...<br>
i don't know if it is supported but a played around with downgrade
and i was able to downgrade from 3.6.7 to 3.5.6 ...on VM's.<br>
in any case (upgrade or downgrade) you should be aware of the
operating version...as far as i can remember i had always to set it
manually.<br>
this was not done automatically by upgrade or downgrade<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/community/documentation/index.php/OperatingVersions">http://www.gluster.org/community/documentation/index.php/OperatingVersions</a><br>
<br>
<br>
downgrade gluster von 3.6.7 auf 3.5.6 :
<br>
situation ... 4 nodes in dist-repl. gfs 3.6.7 + same as geo-rep
slave<br>
<br>
add-apt-repository ppa:gluster/glusterfs-3.5
<br>
<br>
gluster volume geo-replication stop <master> <slave>
<br>
gluster volume stop <volume>
<br>
gluster volume reset <volname> force (save all settings
before...: gluster volume info)
<br>
apt-get update
<br>
apt-get install glusterfs-server=3.5.6-ubuntu1~trusty1
glusterfs-common=3.5.6-ubuntu1~trusty1
glusterfs-client=3.5.6-ubuntu1~trusty1
<br>
gluster volume set all op-version 30500
<br>
gluster volume set <volname> <key> <value>
(for all settings)<br>
gluster volume start <volname><br>
<br>
afterwards i have been faced with two errors :<br>
<br>
a log file in /var/log/glustserfs/... (forgotten which one...)
showed a wrong op-version...a 30600 was still in use while 30500 was
expected. possibly this could be prevented by setting the op-version
before stopping the volume. i'm not sure. i adapted the
/var/lib/glusterd/glusterd.info manually...and as far as i can
remember i was able to start the volume again.<br>
<br>
<br>
then :<br>
<i class="moz-txt-slash"><span class="moz-txt-tag">/</span>var/log/glusterfs/bricks<span
class="moz-txt-tag">/</span></i>...
<br>
2015-12-07 17:59:17.020988] E [graph.y:212:volume_type] 0-parser:
Volume 'myvol-barrier', line 31: type 'features/barrier' is not
valid or not found on this machine
<br>
<br>
another :<br>
gluster volume reset <volume> force
<br>
<br>
sovled the situation. <br>
at least now i was able to start and mount the volume.<br>
<br>
however, when you decide to upgrade to 3.6 it's pretty sure that you
will be faced to the problem that clients cannot mount the volume.<br>
( solved by glusterd --xlator-option *.upgrade=on -N )<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1191176">https://bugzilla.redhat.com/show_bug.cgi?id=1191176</a><br>
<br>
br<br>
dietmar<br>
<br>
<br>
<div class="moz-cite-prefix">Am 12.02.2016 um 14:26 schrieb Dietmar
Putz:<br>
</div>
<blockquote cite="mid:56BDDD70.6050106@3qmedien.net" type="cite">Hi
Dave,
<br>
<br>
based on my experience i would expect problems when old clients
trying to access a volume with an upgraded gfs.
<br>
as mentioned recently i upgraded step by step from 3.4.7 to 3.7.6
and as far as i can remember i had problems with a 3.4.7 client
when accessing a 3.5 volume. because of the geo-replication
problem i was under pressure and have not been focused no such
problems...afterwards i upgraded all the clients as recommended
before they accessed the volume and i never had problems again.
<br>
<br>
...except this little example :
<br>
gluster volume is a 6 node dist.repl. running 14.04 LTS with gfs
3.7.6...the volume is accessed by some 3.7.6 clients and there is
still one client with 12.04 LTS and gfs 3.6.7 (3.7 is not
available on 14.04 :( so i have to update the entire node...).
<br>
two days ago i tried to set the geo-replication.indexing to off.
<br>
<br>
<br>
[ 21:01:49 ] - root@gluster-ger-ber-08
/var/lib/misc/glusterfsd/ger-ber-01 $gluster volume set ger-ber-01
geo-replication.indexing off
<br>
volume set: failed: Staging failed on gluster-ger-ber-12-int.
Error: One or more connected clients cannot support the feature
being set. These clients need to be upgraded or disconnected
before running this command again
<br>
<br>
after disconnecting the client with gfs 3.6.7 (the 3.7.6 clients
are still connected) :
<br>
<br>
[ 21:05:03 ] - root@gluster-ger-ber-08
/var/lib/misc/glusterfsd/ger-ber-01 $gluster volume set ger-ber-01
geo-replication.indexing off
<br>
volume set: success
<br>
[ 21:12:56 ] - root@gluster-ger-ber-08
/var/lib/misc/glusterfsd/ger-ber-01 $
<br>
<br>
afterwards i was able to connect the 3.6.7 client again.
<br>
i don't know all the features being supported by the different gfs
versions but this example should show that they exist.
<br>
a developer could tell you much more about this...
<br>
<br>
i have to mention that i always followed the 'scheduling a
downtime' part like in :
<br>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.5">http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.5</a>
<br>
<br>
hope that helps...
<br>
best regards
<br>
dietmar
<br>
<br>
<br>
On 11.02.2016 23:05, Dave Warren wrote:
<br>
<blockquote type="cite">On 2016-02-11 04:27, Dietmar Putz wrote:
<br>
<blockquote type="cite">and i strongly believe you have to
update all your clients too.
<br>
maybe a developer can give you more background information
about the need to do that...
<br>
</blockquote>
<br>
I intend to update all of my clients as soon as possible -- I
was more concerned about whether the old clients will cause any
problems (to the servers, data integrity, etc) until they're
upgraded?
<br>
<br>
I'd be perfectly willing to block old clients from connecting
(and am willing to do so from the firewall if needed)
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>