<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 29, 2016 at 5:39 AM, Anuradha Talur <span dir="ltr">&lt;<a href="mailto:atalur@redhat.com" target="_blank">atalur@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Response inline.<br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Krutika Dhananjay&quot; &lt;<a href="mailto:kdhananj@redhat.com">kdhananj@redhat.com</a>&gt;<br>
&gt; To: &quot;David Gossage&quot; &lt;<a href="mailto:dgossage@carouselchecks.com">dgossage@carouselchecks.com</a>&gt;<br>
&gt; Cc: &quot;<a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a> List&quot; &lt;<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>&gt;<br>
&gt; Sent: Monday, August 29, 2016 3:55:04 PM<br>
&gt; Subject: Re: [Gluster-users] 3.8.3 Shards Healing Glacier Slow<br>
&gt;<br>
&gt; Could you attach both client and brick logs? Meanwhile I will try these steps<br>
&gt; out on my machines and see if it is easily recreatable.<br>
&gt;<br>
&gt; -Krutika<br>
&gt;<br>
&gt; On Mon, Aug 29, 2016 at 2:31 PM, David Gossage &lt; <a href="mailto:dgossage@carouselchecks.com">dgossage@carouselchecks.com</a><br>
&gt; &gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Centos 7 Gluster 3.8.3<br>
&gt;<br>
&gt; Brick1: ccgl1.gl.local:/gluster1/<wbr>BRICK1/1<br>
&gt; Brick2: ccgl2.gl.local:/gluster1/<wbr>BRICK1/1<br>
&gt; Brick3: ccgl4.gl.local:/gluster1/<wbr>BRICK1/1<br>
&gt; Options Reconfigured:<br>
&gt; cluster.data-self-heal-<wbr>algorithm: full<br>
&gt; cluster.self-heal-daemon: on<br>
&gt; cluster.locking-scheme: granular<br>
&gt; features.shard-block-size: 64MB<br>
&gt; features.shard: on<br>
&gt; performance.readdir-ahead: on<br>
&gt; storage.owner-uid: 36<br>
&gt; storage.owner-gid: 36<br>
&gt; performance.quick-read: off<br>
&gt; performance.read-ahead: off<br>
&gt; performance.io-cache: off<br>
&gt; performance.stat-prefetch: on<br>
&gt; cluster.eager-lock: enable<br>
&gt; network.remote-dio: enable<br>
&gt; cluster.quorum-type: auto<br>
&gt; cluster.server-quorum-type: server<br>
&gt; server.allow-insecure: on<br>
&gt; cluster.self-heal-window-size: 1024<br>
&gt; cluster.background-self-heal-<wbr>count: 16<br>
&gt; performance.strict-write-<wbr>ordering: off<br>
&gt; nfs.disable: on<br>
&gt; nfs.addr-namelookup: off<br>
&gt; nfs.enable-ino32: off<br>
&gt; cluster.granular-entry-heal: on<br>
&gt;<br>
&gt; Friday did rolling upgrade from 3.8.3-&gt;3.8.3 no issues.<br>
&gt; Following steps detailed in previous recommendations began proces of<br>
&gt; replacing and healngbricks one node at a time.<br>
&gt;<br>
&gt; 1) kill pid of brick<br>
&gt; 2) reconfigure brick from raid6 to raid10<br>
&gt; 3) recreate directory of brick<br>
&gt; 4) gluster volume start &lt;&gt; force<br>
&gt; 5) gluster volume heal &lt;&gt; full<br>
Hi,<br>
<br>
I&#39;d suggest that full heal is not used. There are a few bugs in full heal.<br>
Better safe than sorry ;)<br>
Instead I&#39;d suggest the following steps:<br>
<br></blockquote><div>Currently I brought the node down by systemctl stop glusterd as I was getting sporadic io issues and a few VM&#39;s paused so hoping that will help.  I may wait to do this till around 4PM when most work is done in case it shoots load up.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) kill pid of brick<br>
2) to configuring of brick that you need<br>
3) recreate brick dir<br>
4) while the brick is still down, from the mount point:<br>
   a) create a dummy non existent dir under / of mount.<br></blockquote><div><br></div><div>so if noee 2 is down brick, pick node for example 3 and make a test dir under its brick directory that doesnt exist on 2 or should I be dong this over a gluster mount? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   b) set a non existent extended attribute on / of mount.<br></blockquote><div><br></div><div>Could you give me an example of an attribute to set?   I&#39;ve read a tad on this, and looked up attributes but haven&#39;t set any yet myself.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Doing these steps will ensure that heal happens only from updated brick to down brick.<br>
5) gluster v start &lt;&gt; force<br>
6) gluster v heal &lt;&gt;<br></blockquote><div><br></div><div>Will it matter if somewhere in gluster the full heal command was run other day?  Not sure if it eventually stops or times out. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;<br>
&gt; 1st node worked as expected took 12 hours to heal 1TB data. Load was little<br>
&gt; heavy but nothing shocking.<br>
&gt;<br>
&gt; About an hour after node 1 finished I began same process on node2. Heal<br>
&gt; proces kicked in as before and the files in directories visible from mount<br>
&gt; and .glusterfs healed in short time. Then it began crawl of .shard adding<br>
&gt; those files to heal count at which point the entire proces ground to a halt<br>
&gt; basically. After 48 hours out of 19k shards it has added 5900 to heal list.<br>
&gt; Load on all 3 machnes is negligible. It was suggested to change this value<br>
&gt; to full cluster.data-self-heal-<wbr>algorithm and restart volume which I did. No<br>
&gt; efffect. Tried relaunching heal no effect, despite any node picked. I<br>
&gt; started each VM and performed a stat of all files from within it, or a full<br>
&gt; virus scan and that seemed to cause short small spikes in shards added, but<br>
&gt; not by much. Logs are showing no real messages indicating anything is going<br>
&gt; on. I get hits to brick log on occasion of null lookups making me think its<br>
&gt; not really crawling shards directory but waiting for a shard lookup to add<br>
&gt; it. I&#39;ll get following in brick log but not constant and sometime multiple<br>
&gt; for same shard.<br>
&gt;<br>
&gt; [2016-08-29 08:31:57.478125] W [MSGID: 115009]<br>
&gt; [server-resolve.c:569:server_<wbr>resolve] 0-GLUSTER1-server: no resolution type<br>
&gt; for (null) (LOOKUP)<br>
&gt; [2016-08-29 08:31:57.478170] E [MSGID: 115050]<br>
&gt; [server-rpc-fops.c:156:server_<wbr>lookup_cbk] 0-GLUSTER1-server: 12591783:<br>
&gt; LOOKUP (null) (00000000-0000-0000-00<br>
&gt; 00-000000000000/241a55ed-f0d5-<wbr>4dbc-a6ce-ab784a0ba6ff.221) ==&gt; (Invalid<br>
&gt; argument) [Invalid argument]<br>
&gt;<br>
&gt; This one repeated about 30 times in row then nothing for 10 minutes then one<br>
&gt; hit for one different shard by itself.<br>
&gt;<br>
&gt; How can I determine if Heal is actually running? How can I kill it or force<br>
&gt; restart? Does node I start it from determine which directory gets crawled to<br>
&gt; determine heals?<br>
&gt;<br>
&gt; David Gossage<br>
&gt; Carousel Checks Inc. | System Administrator<br>
&gt; Office 708.613.2284<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Gluster-users mailing list<br>
&gt; <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
&gt; <a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-users</a><br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Gluster-users mailing list<br>
&gt; <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
&gt; <a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-users</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thanks,<br>
Anuradha.<br>
</font></span></blockquote></div><br></div></div>