<div dir="ltr">HI Mohammed,<div><br></div><div>Its not a bug per se, its a configuration and documentation issue. I searched the gluster documentation pretty thoroughly and I did not find anything that discussed the 1) client's call graph and 2) how to specifically configure a native glusterfs client to properly specify that call graph so that replication will happen across multiple bricks. If its there, then there's a pretty severe organization issue in the documentation (I am pretty sure I ended up reading almost every page actually).</div><div><br></div><div>As a result, because I was a new to gluster, my initial set up really confused me. I would follow the instructions as documented in official gluster docs (execute the mount command), write data on the mount...and then only see it replicated to a single brick. It was only after much furious googling did I manage to figure out that that 1) i needed a client configuration file which should be specified in /etc/fstab and 2) that configuration block mentioned above was the key.</div><div><br></div><div>I am actually planning on submitting a PR to the documentation to cover all this. To be clear, I am sure this is obvious to a seasoned gluster user -- but it is not at all obvious to someone who is new to gluster such as myself.</div><div><br></div><div>So I am an operations engineer. I like reproducible deployments and I like monitoring to alert me when something is wrong. Due to human error or a bug in our deployment code, its possible that something like not setting the client call graph properly could happen. I wanted a way to detect this problem so that if it does happen, it can be remediated immediately.</div><div><br></div><div>Your suggestion sounds promising. I shall definitely look into that. Though that might be a useful information to surface up in a CLI command in a future gluster release IMHO.</div><div><br></div><div>Joe</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 23, 2017 at 11:51 PM, Mohammed Rafi K C <span dir="ltr"><<a href="mailto:rkavunga@redhat.com" target="_blank">rkavunga@redhat.com</a>></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"><span class="">
<p><br>
</p>
<br>
<div class="m_685628515331254346moz-cite-prefix">On 02/23/2017 11:12 PM, Joseph
Lorenzini wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>I have a simple replicated volume with a replica count of
3. To ensure any file changes (create/delete/modify) are
replicated to all bricks, I have this setting in my client
configuration.</div>
<div>
<p class="m_685628515331254346gmail-p1"><span class="m_685628515331254346gmail-s1"> volume
gv0-replicate-0<br>
</span> type cluster/replicate <br>
subvolumes gv0-client-0 gv0-client-1 gv0-client-2<br>
end-volume</p>
<p class="m_685628515331254346gmail-p1">And that works as expected. My question is
how one could detect if this was not happening which could
poise a severe problem with data consistency and
replication. For example, those settings could be omitted
from the client config and then the client will only write
data to one brick and all kinds of terrible things will
start happening. I have not found a way the gluster volume
cli to detect when that kind of problem is occurring. For
example gluster volume heal <volname> info does not
detect this problem. </p>
<p class="m_685628515331254346gmail-p1">Is there any programmatic way to detect
when this problem is occurring?<br>
</p>
</div>
</div>
</blockquote>
<br></span>
I couldn't understand how you will end up in this situation. There
is only one possibility (assuming there is no bug :) ), ie you
changed the client graph in a way that there is only one subvolume
to replica server.<br>
<br>
To check that the simply way is, there is a xlator called meta,
which provides meta data information through mount point, similiar
to linux proc file system. So you can check the active graph through
meta and see the number of subvolumes for replica xlator<br>
<br>
for example : the directory <mount
point>/.meta/graphs/active/<<wbr>volname>-replicate-0/<wbr>subvolumes
will have entries for each replica clients , so in your case you
should see 3 directories.<br>
<br>
<br>
Let me know if this helps.<br>
<br>
Regards<br>
Rafi KC<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<p class="m_685628515331254346gmail-p1">Thanks,<br>
Joe</p>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="m_685628515331254346mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Gluster-users mailing list
<a class="m_685628515331254346moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a>
<a class="m_685628515331254346moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-users</a></pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div>