<div dir="ltr">Setting in xdata has the benefit of getting propagated to server side without change in protocol. However that being said, dict_t in its current form is not the most efficient data structure for storing a lot of key/values (biggest concern being too many small allocations). It will be good to revive <a href="http://review.gluster.org/3910">http://review.gluster.org/3910</a> so that such use of xdata will be of a lesser concern.<div>
<br></div><div>Avati<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 12:12 AM, Raghavendra Bhat <span dir="ltr"><<a href="mailto:rabhat@redhat.com" target="_blank">rabhat@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
As of now, the performance xlators cache the data and perform some optimizations for all the fops irrespective of whether the fop is generated from the application or internal xlator. I think, performance xlators should come in to picture for only the fops generated by the applications. Imagine the situation where a graph change happens and fuse xlator sends open call on the fds to migrate them to the new graph. But the open call might not reach posix if open-behind unwinds success to fuse xlator.<br>
<br>
It can be done in 2 ways.<br>
<br>
1) Set a key in dictionary if the call is generated internally<br>
OR<br>
2) Set a flag in the callstack itself, whether the fop is internal fop or generated from the application.<br>
<br>
Please provide feedback.<br>
<br>
<br>
Regards,<br>
Raghavendra Bhat<br>
<br>
______________________________<u></u>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/<u></u>mailman/listinfo/gluster-devel</a><br>
</blockquote></div><br></div></div></div>