<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 27 January 2017 at 19:05, Kevin Lemonnier <span dir="ltr"><<a href="mailto:lemonnierk@ulrar.net" target="_blank">lemonnierk@ulrar.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Basically, every now & then I notice random VHD images popping up in the<br>
> heal queue, and they're almost always in pairs, "healing" the same file on<br>
> 2 of the 3 replicate bricks.<br>
> That already strikes me as odd, as if a file is "dirty" on more than one<br>
> brick, surely that's a split-brain scenario? (nothing logged in "info<br>
> split-brain" though)<br>
<br>
</span>I don't think that's a problem, they do tend to show the heal on every brick<br>
but the one being healed .. I think the sources show the file to heal, not the<br>
dirty one.<br>
At least that's what I noticed on my clusters.<br>
<span class=""><br>
><br>
> Anyway, these heal processes always hang around for a couple of hours, even<br>
> when it's just metadata on an arbiter brick.<br>
> That doesn't make sense to me, an arbiter shouldn't take more than a couple<br>
> of seconds to heal!?<br>
<br>
</span>Sorry, no idea on that, I never used arbiter setups.<span class=""><br></span></blockquote><div><br></div><div>If it's actually showing the source files that are being healed *from*, not *to*, that'd make sense. Although it's a counter-intuitive way of displaying things & is completely contrary to all of the documentation (as described by <a href="http://readthedocs.gluster.io">readthedocs.gluster.io</a>, Red Hat & Rackspace)<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> I spoke with Joe on IRC, and he suggested I'd find more info in the<br>
> client's logs...<br>
<br>
</span>Well it'd be good to know why they need healing, for sure.<br>
I don't know of any way to get that on the gluster side, you need to<br>
find a way on oVirt to redirect the output of the qemu process somewhere.<br>
That's where you'll find the libgfapi logs.<br>
Never used oVirt so I can't really help on that :/<br>
</blockquote><div><br></div><div>Well you've given me somewhere to start from at least.<br><br></div><div>Appreciated!<br><br></div><div>D<br></div></div></div></div>