<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/22/2017 11:02 AM, WK wrote:<br>
</div>
<blockquote
cite="mid:15c8802f-a1de-674f-c579-d769a19f2a7b@bneit.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 5/21/2017 7:00 PM, Ravishankar N
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2c6a72c6-fe69-538b-14fa-ffa6f48d6443@redhat.com">
<meta http-equiv="Context-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">On 05/22/2017 03:11 AM, W Kern
wrote:<br>
</div>
<blockquote
cite="mid:7a9bfbc2-09d7-8d3a-1190-992126bb6766@bneit.com"
type="cite"><br>
<p>gluster volume set VOL cluster.quorum-type none</p>
<p>from the remaining 'working' node1 and it simply responds
with</p>
<p>"volume set: failed: Quorum not met. Volume operation not
allowed"</p>
<p>how do you FORCE gluster to ignore the quorum in such a
situation? <br>
</p>
</blockquote>
You probably also have server quorum enabled
(cluster.server-quorum-type = server). Server quorum enforcement
does not allow modifying volume options or other actions like
peer probing/detaching if server quorum is not met.<br>
<br>
</blockquote>
<br>
Great, that worked. ie gluster volume set VOL
cluster.server-quorum-type none<br>
<br>
Although I did get an error of "Volume set: failed: Commit failed
on localhost, please check the log files for more details"<br>
<br>
but then I noticed that volume immediately came back up and I was
able to mount the single remaining node and access those files.<br>
<br>
So you need to do both settings in my scenario.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:2c6a72c6-fe69-538b-14fa-ffa6f48d6443@redhat.com">
Also, don't disable client quorum for arbiter volumes or you
will end up corrupting the files. For instance, if the arbiter
brick was the only one that is up, and you disabled client
quorum, then a writev from the application will get a success
but nothing will ever get written on-disk on the arbiter brick.<br>
</blockquote>
<br>
Yes, I am learning the pro/cons of arbiter and understand their
limitations.<br>
<br>
In this test case, I had taken the arbiter OFFLINE (deliberately)
and I was rehearsing a scenario where only one of the two real
copies survived and I needed that data. Hopefully that is an
unlikely scenario and we would have backups, but I've earned the
grey specs in my hair and the Original Poster who started this
thread run into that exact scenario.<br>
<br>
On our older Gluster installs without sharding, the files are
simply sitting there on the disk if you need them. That is
enormously comforting and means you can be a little less paranoid
compared to other distributed storage schemes we use/have used.<br>
<br>
But then I have my next question:<br>
<br>
Is it possible to recreate a large file (such as a VM image) from
the raw shards outside of the Gluster environment if you only had
the raw brick or volume data?<br>
<br>
From the docs, I see you can identify the shards by the GFID<br>
<br>
<pre class="screen"># getfattr -d -m. -e hex <em class="replaceable">path_to_file</em></pre>
# ls /bricks/*/.shard -lh | grep <em class="replaceable">GFID<br>
<br>
Is there a gluster tool/script that will recreate the file?<br>
<br>
or can you just sort them sort them properly and then simply
cat/copy+ them back together?<br>
<br>
cat shardGFID.1 .. shardGFID.X > thefile<br>
</em></blockquote>
<br>
Yes, this should work, but you would need to include the base file
(the 0th shard, if you will) first in the list of files that you're
stitching up. In the happy case, you can test it by comparing the
md5sum of the file from the mount to that of your stitched file.<br>
-Ravi<br>
<blockquote
cite="mid:15c8802f-a1de-674f-c579-d769a19f2a7b@bneit.com"
type="cite"><em class="replaceable"> <br>
Thank You though, the sharding should be a big win.<br>
<br>
-bill</em><br>
<em class="replaceable"></em>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>