<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>3.7.13 has been running well now for several weeks for me on a
rep 3 sharded volume, VM hosting, but I'm still on op-version
30710, after the issues with 12 have held off making any changes
until confidence was restored :)</p>
<p><br>
</p>
<p>Scrolling through the code revealed the following for 3.7.13</p>
<p><br>
</p>
<p><b>cluster.shd-max-threads</b><br>
Default Value: 1<br>
Description: Maximum number of threads SHD can use per local
brick. This can substantially lower heal times, but can also
crush your bricks if you don't have the storage hardware to
support this.<br>
<br>
<b>cluster.shd-wait-qlength</b><br>
Default Value: 1024<br>
Description: This option can be used to control number of heals
that can wait in SHD per subvolume<br>
<br>
<b>cluster.locking-scheme</b><br>
Default Value: full<br>
Description: If this option is set to granular, self-heal will
stop being compatible with afr-v1, which helps afr be more
granular while self-healing<br>
<br>
</p>
<p>The first two are I believe, to do with improving heal
performance. However I'm quite happy with the existing defaults
and performance, so no need to tweak them.</p>
<p><br>
</p>
<p>But I'm not sure as setting cluster.locking-scheme to"granular"
will achieve - I seem to recall that it reduces the locks needs to
establish whats needs to be healed? improves speed of "heal info"?</p>
<p><br>
</p>
<p>thanks,<br>
</p>
<br>
<pre class="moz-signature" cols="72">--
Lindsay Mathieson</pre>
</body>
</html>