<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div>I faced the same issue with the sharding translator. I fixed it by making its readdirp callback initialize individual entries' inode ctx, some of these being xattr values, which are filled in entry->dict by the posix translator.<br></div><div>Here is the patch that got merged recently: <a href="http://review.gluster.org/11854">http://review.gluster.org/11854</a><br></div><div>Would that be as easy to do in DHT as well?<br></div><div><br></div><div>As far as AFR is concerned, it indirectly forces LOOKUP on entries which are being retrieved for the first time through a READDIRP (and as a result do not have their inode ctx etc initialised yet) by setting entry->inode to NULL. See afr_readdir_transform_entries().</div><div>This is the default behavior which is being made optional as part of <a href="http://review.gluster.org/#/c/11846/">http://review.gluster.org/#/c/11846/</a> which is still under review (see BZ 1250803, a performance bug :) ).<br></div><div><br></div><div>-Krutika<br></div><div><br></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>"Mohammed Rafi K C" <rkavunga@redhat.com><br><b>To: </b>"Gluster Devel" <gluster-devel@gluster.org><br><b>Cc: </b>"Dan Lambright" <dlambrig@redhat.com>, "Nithya Balachandran" <nbalacha@redhat.com>, "Raghavendra Gowdappa" <rgowdapp@redhat.com>, "Ben Turner" <bturner@redhat.com>, "Ben England" <bengland@redhat.com>, "Manoj Pillai" <mpillai@redhat.com>, "Pranith Kumar Karampuri" <pkarampu@redhat.com>, "Ravishankar Narayanankutty" <ranaraya@redhat.com>, kdhananj@redhat.com, xhernandez@datalab.es<br><b>Sent: </b>Wednesday, August 12, 2015 7:29:48 PM<br><b>Subject: </b>Inconsistent behavior due to lack of lookup on entry followed by readdirp<br><div><br></div>Hi All,<br><div><br></div>We are facing some inconsistent behavior for fops like rename, unlink<br>etc due to lack of lookup followed by a readdirp, more specifically if<br>inodes/gfid are populated via readdirp call and this nodeid is shared<br>with kernal, md-cache will cache this based on base-name. Then<br>subsequent named lookup will be served from md-cache and it winds-back<br>immediately. So there is a chance to have an FOP triggered with out<br>having a lookup on an entry. DHT does lot of things like creating link<br>files and populate inode_ctx etc, during lookup. In such scenario it is<br>must to have at least one lookup to be happened on an entry. Since<br>readdirp preventing the lookup, it has been very hard for fops to<br>proceed without a first lookup on the entry. We are also suspecting some<br>problems due to same with afr/ec self healing also. So If we remove<br>readdirp from md-cache ([1], [2]) it causes, an additional hop for first<br>lookup for every entry. I'm mostly concerned with this one extra network<br>call, and the performance degradation caused by the same.<br><div><br></div>Now with this, the only advantage with readdirp is, it removes one<br>context switch between kernal and userspace. Is it really worth to<br>sacrifice this for consistency ?<br><div><br></div>What do you think about removing readdirp functionality?<br><div><br></div>Please provide your input/suggestion/ideas.<br><div><br></div>[1] : http://review.gluster.org/#/c/11892/<br><div><br></div>[2] : http://review.gluster.org/#/c/11894/<br><div><br></div>Thanks in Advance<br>Rafi KC<br></blockquote><div><br></div></div></body></html>