<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div>Hi,</div><div><br></div><div>The following patch fixes an issue with readdir(p) in shard xlator: <a href="http://review.gluster.org/#/c/10809/">http://review.gluster.org/#/c/10809/</a> whose details can be found in the commit message.</div><div><br></div><div>One side effect of this is that from shard xlator, the size of the dirents list returned to the translators above it could be greater than the</div><div>requested size in the wind path (thanks to Pranith for pointing this out during the review of this patch), with the worst-case scenario returning (2 * requested_size) worth of entries.</div><div>For example, if fuse requests readdirp with 128k as the size, in the worst case, 256k worth of entries could be unwound in return.</div><div>How important is it to strictly adhere to this size limit in each iteration of readdir(p)? And what are the repercussions of such behavior?</div><div><br></div><div>Note:</div><div>I tried my hand at simulating this issue on my volume but I have so far been unsuccessful at hitting this test case.</div><div>Creating large number of files on the root of a sharded volume, triggering readdirp on it until ".shard" becomes the last entry read in a given iteration, winding the next</div><div>readdirp from shard xlator, and then concatenating the results of two readdirps into one is proving to be an exercise in futility.</div><div>Therefore, I am asking this question here to know what could happen "in theory" in such situations.</div><div><br></div><div>-Krutika</div><div><br></div></div></body></html>