[Gluster-devel] Regarding the size parameter in readdir(p) fops

[Krutika Dhananjay]

Hi, 

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. 

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 
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. 
For example, if fuse requests readdirp with 128k as the size, in the worst case, 256k worth of entries could be unwound in return. 
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? 

Note: 
I tried my hand at simulating this issue on my volume but I have so far been unsuccessful at hitting this test case. 
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 
readdirp from shard xlator, and then concatenating the results of two readdirps into one is proving to be an exercise in futility. 
Therefore, I am asking this question here to know what could happen "in theory" in such situations. 

-Krutika 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150519/bf15b5ca/attachment.html>