<div dir="ltr"><div dir="auto"><div>If you are not using applications that rely on 100% metadata consistency, like Databases, Kafka, AMQ etc. you can use the below mentioned volume options:<br><br><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"># gluster volume set <volname> group metadata-cache<br></span></span><br><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"># gluster volume set <volname> network.inode-lru-limit 200000<br></span></span><br><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"># gluster volume set <VOLNAME> performance.readdir-ahead on<br></span></span></span></span><br><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"># gluster volume set <VOLNAME> performance.parallel-readdir on<br><br>For more information refer to [1]<br><br></span></span></span></span></span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1">Also, which version og Gluster are you using? Its preferred to use 3.11 or above for these perf enhancements.<br></span></span></span></span></span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1">Note that parallel-readdir is going to help in increasing the ls -l performance drastically in your case, but there are few corner case known issues.<br><br></span></span></span></span></span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1">Regards,<br></span></span></span></span></span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1">Poornima<br></span></span></span></span></span></span></div><div><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><span class="gmail-blob-code-inner"><span class="gmail-pl-c1"><br></span></span></span></span></span></span>[1] <a href="https://github.com/gluster/glusterdocs/pull/342/files#diff-62f536ad33b2c2210d023b0cffec2c64">https://github.com/gluster/glusterdocs/pull/342/files#diff-62f536ad33b2c2210d023b0cffec2c64</a><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 30, 2018, 8:29 PM Yanfei Wang <<a href="mailto:backyes@gmail.com" target="_blank">backyes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi experts on glusterFS,<br>
<br>
In our testbed, we found that the ' ls -l' performance is pretty slow.<br>
Indeed from the prospect of glusterFS design space, we need to avoid<br>
'ls ' directory which will traverse all bricks sequentially in our<br>
current knowledge.<br>
<br>
We use generic setting for our testbed:<br>
<br>
```<br>
Volume Name: gv0<br>
Type: Distributed-Replicate<br>
Volume ID: 4a6f96f8-b3fb-4550-bd19-<wbr>e1a5dffad4d0<br>
Status: Started<br>
Snapshot Count: 0<br>
Number of Bricks: 19 x 3 = 57<br>
Transport-type: tcp<br>
Bricks:<br>
...<br>
Options Reconfigured:<br>
features.inode-quota: off<br>
features.quota: off<br>
cluster.quorum-reads: on<br>
cluster.quorum-count: 2<br>
cluster.quorum-type: fixed<br>
transport.address-family: inet<br>
nfs.disable: on<br>
performance.client-io-threads: off<br>
cluster.server-quorum-ratio: 51%<br>
<br>
```<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Carefully consulting docs, the NFS client is preferred client solution<br>
for better 'ls' performance. However, this better performance comes<br>
from caching meta info locally, I think, and the caching mechanism<br>
will cause the penalty of data coherence, right?<br>
<br>
I want to know what's the best or mature way to trade-off the 'ls '<br>
performance with data coherence in in reality? Any comments are<br>
welcome.<br>
<br>
Thanks.<br>
<br>
-Fei<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" rel="noreferrer" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
</blockquote></div></div></div>
</div>