<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div>Sorry for the late reply, Niels.</div><div><br></div><div>I tried what you suggested yesterday and yes, like you predicted, the extra entries are getting dropped by fuse-bridge, and the readdir-ahead translator seems to be showing the same behavior.</div><div>Thanks for the idea. :)</div><div><br></div><div>-Krutika</div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Niels de Vos" <ndevos@redhat.com><br><b>To: </b>"Krutika Dhananjay" <kdhananj@redhat.com><br><b>Cc: </b>"Gluster Devel" <gluster-devel@gluster.org><br><b>Sent: </b>Tuesday, May 19, 2015 3:12:20 PM<br><b>Subject: </b>Re: [Gluster-devel] Regarding the size parameter in readdir(p) fops<br><div><br></div>On Tue, May 19, 2015 at 05:12:35AM -0400, Krutika Dhananjay wrote:<br>> Hi, <br>> <br>> The following patch fixes an issue with readdir(p) in shard xlator: http://review.gluster.org/#/c/10809/ whose details can be found in the commit message. <br>> <br>> 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 <br>> 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. <br>> For example, if fuse requests readdirp with 128k as the size, in the worst case, 256k worth of entries could be unwound in return. <br>> 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? <br>> <br>> Note: <br>> I tried my hand at simulating this issue on my volume but I have so far been unsuccessful at hitting this test case. <br>> 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 <br>> readdirp from shard xlator, and then concatenating the results of two readdirps into one is proving to be an exercise in futility. <br>> Therefore, I am asking this question here to know what could happen "in theory" in such situations. <br><div><br></div>How about modifying xlators/mount/fuse/src/fuse-bridge.c and increasing<br>the size of the readdir(p) argument there? The FUSE kernel side would<br>not know about the increased size, but the other xlators would request<br>a bigger size in subsequent readdir(p) FOPs.<br><div><br></div>I suspect that the additional dentries in readdir(p) get dropped, and<br>the next getdents() call from the kernel continues are the offset of the<br>readdir(p) of the last returned dentry.<br><div><br></div>Niels<br></blockquote><div><br></div></div></body></html>