<html><head></head><body>Personally, I like the third option provided that doesn&#39;t cause memory issues.<br>
<br>
In fact, read the whole thing, transfer it to the client and let the client handle the posix syntax.<br>
<br>
Optionally add a path cache timeout client side that stores the directory listing for a period of time to mitigate the &quot;php&quot; dilemma for those types of use cases. <br>
 <br><br><div class="gmail_quote">On September 13, 2014 12:02:55 PM PDT, manu@netbsd.org wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">In &lt;1lrx1si.n8tms1igmi5pM%manu@netbsd.org&gt; I explained why NetBSD<br />currently fails self-heald.t, but since the subjet is burried deep in a<br />thread, it might be worth starting a new one to talk about how to fix.<br /><br />In 3 places within glusterfs code (features/index,<br />features/snapview-server and storage/posix), a server component answers<br />readdir requests on a directory which may be split in mulitple calls.<br /><br />To answer one call, we have the following library calls:<br />- opendir()<br />- seekdir() to resume where the previous request was<br />- readdir()<br />- telldir() to record where we are for the next request<br />- closedir()<br /><br />This relies on unspecified behavior, as POSIX says: "The value of loc<br />should have been returned from an earlier call to telldir() using the<br />same directory stream."<br /><a
href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/seekdir.html">http://pubs.opengroup.org/onlinepubs/9699919799/functions/seekdir.html</a><br /><br />Since we do opendir() and closedir() at each time, we do not use the<br />same directory stream. It causes an infinite loop on NetBSD because it<br />badly resume from previous request, and in the general case it will<br />break badly if an entry is added in the directory between two requests.<br /><br />How can we fix that?<br /><br />1) we can keep the directory stream open. The change is intrusive since<br />we will need a chained list of open contexts, and we need to clean them<br />if they timeout.<br /><br />2) in order to keep state between requests, we can use the entry index<br />(first encoutered is 1, and so on) instead of values returned by<br />telldir(). That works around the unspecified behavior, but it still<br />breaks if directory content is changed between two requests<br /><br />3) make sure the
readdir is done in a single request. That means trying<br />with bigger buffers until it works. For instance  in<br />xlator/cluster/afr/src/afr-self-heald.c we have:<br />   while ((ret = syncop_readdir (subvol, fd, 131072, offset, &amp;entries)))<br /><br />We would use -1 instead of 131072 to tell that we want everything<br />without a size limit, and the server component (here features/index)<br />would either return everyting or fail, whithout playing with<br />telldir/seekdir.<br /><br />Opinions? The third solution seems the best to me since it is not very<br />intrusive and it makes things simplier. Indeed we allow unbound data<br />size to come back from the brick to glustershd, but we trust the brick,<br />right?<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>