<div dir="ltr">With the tests conducted, I could not find any evidence of a performance regression in quick-read.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 11:01 AM, Raghavendra G <span dir="ltr">&lt;<a href="mailto:raghavendra.hg@gmail.com" target="_blank">raghavendra.hg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think this caused regression in quick-read. On going through code, I realized Quick-read doesn&#39;t fetch content of a file pointed by dentry in readdirplus. Since, the patch in question prevents any lookup from resolver, reads on the file till the duration of &quot;entry-timeout&quot; (a cmdline option to fuse mount, whose default value is 1 sec) after the entry was discovered in readdirplus will not be served by quick-read even though the size of file is eligible to be cached. This may cause perf regression in read heavy workloads on smallfiles. We&#39;ll be doing more testing to identify this.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 11:31 AM, Raghavendra G <span dir="ltr">&lt;<a href="mailto:raghavendra.hg@gmail.com" target="_blank">raghavendra.hg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Update. Two more days to go for the deadline. Till now, there are no open issues identified against this patch.<br></div><div class="gmail_extra"><div><div class="m_723269619931310581h5"><br><div class="gmail_quote">On Fri, Sep 8, 2017 at 6:54 AM, Raghavendra Gowdappa <span dir="ltr">&lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
----- Original Message -----<br>
&gt; From: &quot;FNU Raghavendra Manjunath&quot; &lt;<a href="mailto:rabhat@redhat.com" target="_blank">rabhat@redhat.com</a>&gt;<br>
&gt; To: &quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;<br>
&gt; Cc: &quot;Raghavendra G&quot; &lt;<a href="mailto:raghavendra.hg@gmail.com" target="_blank">raghavendra.hg@gmail.com</a>&gt;, &quot;Nithya Balachandran&quot; &lt;<a href="mailto:nbalacha@redhat.com" target="_blank">nbalacha@redhat.com</a>&gt;, <a href="mailto:anoopcs@redhat.com" target="_blank">anoopcs@redhat.com</a>,<br>
&gt; &quot;Gluster Devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;, &quot;Raghavendra Bhat&quot; &lt;<a href="mailto:raghavendra@redhat.com" target="_blank">raghavendra@redhat.com</a>&gt;<br>
&gt; Sent: Thursday, September 7, 2017 6:44:51 PM<br>
&gt; Subject: Re: [Gluster-devel] Need inputs on patch #17985<br>
&gt;<br>
</span><span>&gt; From snapview client perspective one important thing to note. For building<br>
&gt; the context for the entry point (by default &quot;.snaps&quot;) a explicit lookup has<br>
&gt; to be done on it. The dentry for &quot;.snaps&quot; is not returned when readdir is<br>
&gt; done on its parent directory (Not even when ls -a is done). So for building<br>
&gt; the context of .snaps (in the context snapview client saves the information<br>
&gt; about whether it is a real inode or virtual inode) we need a lookup.<br>
<br>
</span>Since the dentry corresponding to &quot;.snaps&quot; is not returned, there won&#39;t be an inode for this directory linked in itable. Also, glusterfs wouldn&#39;t have given nodeid corresponding to &quot;.snaps&quot; during readdir response (as dentry itself is not returned). So, kernel would do an explicit lookup before doing any operation on &quot;.snaps&quot; (unlike for those dentries which contain nodeid kernel can choose to skip a lookup) and we are safe. So, #17985 is safe in its current form.<br>
<span><br>
&gt;<br>
&gt; From snapview server perspective as well a lookup might be needed. In<br>
&gt; snapview server a glfs handle is established between the snapview server<br>
&gt; and the snapshot brick. So a inode in snapview server process contains the<br>
&gt; glfs handle for the object being accessed from snapshot.  In snapview<br>
&gt; server readdirp does not build the inode context (which contains the glfs<br>
&gt; handle etc) because glfs handle is returned only in lookup.<br>
<br>
</span>Same argument I&#39;ve given holds good for this case too. Important point to note is that &quot;there is no dentry and hence no nodeid corresponding to .snaps is passed to kernel and kernel is forced to do an explicit lookup&quot;.<br>
<div class="m_723269619931310581m_1623044859594949402HOEnZb"><div class="m_723269619931310581m_1623044859594949402h5"><br>
&gt;<br>
&gt; Regards,<br>
&gt; Raghavendra<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Aug 29, 2017 at 12:53 AM, Raghavendra Gowdappa &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ----- Original Message -----<br>
&gt; &gt; &gt; From: &quot;Raghavendra G&quot; &lt;<a href="mailto:raghavendra.hg@gmail.com" target="_blank">raghavendra.hg@gmail.com</a>&gt;<br>
&gt; &gt; &gt; To: &quot;Nithya Balachandran&quot; &lt;<a href="mailto:nbalacha@redhat.com" target="_blank">nbalacha@redhat.com</a>&gt;<br>
&gt; &gt; &gt; Cc: &quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;, <a href="mailto:anoopcs@redhat.com" target="_blank">anoopcs@redhat.com</a>,<br>
&gt; &gt; &quot;Gluster Devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;,<br>
&gt; &gt; &gt; <a href="mailto:raghavendra@redhat.com" target="_blank">raghavendra@redhat.com</a><br>
&gt; &gt; &gt; Sent: Tuesday, August 29, 2017 8:52:28 AM<br>
&gt; &gt; &gt; Subject: Re: [Gluster-devel] Need inputs on patch #17985<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On Thu, Aug 24, 2017 at 2:53 PM, Nithya Balachandran &lt;<br>
&gt; &gt; <a href="mailto:nbalacha@redhat.com" target="_blank">nbalacha@redhat.com</a>&gt;<br>
&gt; &gt; &gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; It has been a while but iirc snapview client (loaded abt dht/tier etc)<br>
&gt; &gt; had<br>
&gt; &gt; &gt; &gt; some issues when we ran tiering tests. Rafi might have more info on<br>
&gt; &gt; this -<br>
&gt; &gt; &gt; &gt; basically it was expecting to find the inode_ctx populated but it was<br>
&gt; &gt; not.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks Nithya. @Rafi, @Raghavendra Bhat, is it possible to take the<br>
&gt; &gt; &gt; ownership of,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; * Identifying whether the patch in question causes the issue?<br>
&gt; &gt;<br>
&gt; &gt; gf_svc_readdirp_cbk is setting relevant state in inode [1]. I quickly<br>
&gt; &gt; checked whether its the same state stored by gf_svc_lookup_cbk and it looks<br>
&gt; &gt; like the same state. So, I guess readdirp is handled correctly by<br>
&gt; &gt; snapview-client and an explicit lookup is not required. But, will wait for<br>
&gt; &gt; inputs from rabhat and rafi.<br>
&gt; &gt;<br>
&gt; &gt; [1] <a href="https://github.com/gluster/glusterfs/blob/master/xlators/" rel="noreferrer" target="_blank">https://github.com/gluster/glu<wbr>sterfs/blob/master/xlators/</a><br>
&gt; &gt; features/snapview-client/src/s<wbr>napview-client.c#L1962<br>
&gt; &gt;<br>
&gt; &gt; &gt; * Send a fix or at least evaluate whether a fix is possible.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; @Others,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; With the motivation of getting some traction on this, Is it ok if we:<br>
&gt; &gt; &gt; * Set a deadline of around 15 days to complete the review (or testing<br>
&gt; &gt; with<br>
&gt; &gt; &gt; the patch in question) of respective components and to come up with<br>
&gt; &gt; issues<br>
&gt; &gt; &gt; (if any).<br>
&gt; &gt; &gt; * Post the deadline, if there are no open issues, go ahead and merge the<br>
&gt; &gt; &gt; patch?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If time is not enough, let us know and we can come up with a reasonable<br>
&gt; &gt; &gt; time.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; regards,<br>
&gt; &gt; &gt; Raghavendra<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; On 24 August 2017 at 10:13, Raghavendra G &lt;<a href="mailto:raghavendra.hg@gmail.com" target="_blank">raghavendra.hg@gmail.com</a>&gt;<br>
&gt; &gt; &gt; &gt; wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; Note that we need to consider xlators on brick stack too. I&#39;ve added<br>
&gt; &gt; &gt; &gt;&gt; maintainers/peers of xlators on brick stack. Please explicitly<br>
&gt; &gt; ack/nack<br>
&gt; &gt; &gt; &gt;&gt; whether this patch affects your component.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; For reference, following are the xlators loaded in brick stack<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; storage/posix<br>
&gt; &gt; &gt; &gt;&gt; features/trash<br>
&gt; &gt; &gt; &gt;&gt; features/changetimerecorder<br>
&gt; &gt; &gt; &gt;&gt; features/changelog<br>
&gt; &gt; &gt; &gt;&gt; features/bitrot-stub<br>
&gt; &gt; &gt; &gt;&gt; features/access-control<br>
&gt; &gt; &gt; &gt;&gt; features/locks<br>
&gt; &gt; &gt; &gt;&gt; features/worm<br>
&gt; &gt; &gt; &gt;&gt; features/read-only<br>
&gt; &gt; &gt; &gt;&gt; features/leases<br>
&gt; &gt; &gt; &gt;&gt; features/upcall<br>
&gt; &gt; &gt; &gt;&gt; performance/io-threads<br>
&gt; &gt; &gt; &gt;&gt; features/selinux<br>
&gt; &gt; &gt; &gt;&gt; features/marker<br>
&gt; &gt; &gt; &gt;&gt; features/barrier<br>
&gt; &gt; &gt; &gt;&gt; features/index<br>
&gt; &gt; &gt; &gt;&gt; features/quota<br>
&gt; &gt; &gt; &gt;&gt; debug/io-stats<br>
&gt; &gt; &gt; &gt;&gt; performance/decompounder<br>
&gt; &gt; &gt; &gt;&gt; protocol/server<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; For those not following this thread, the question we need to answer<br>
&gt; &gt; is,<br>
&gt; &gt; &gt; &gt;&gt; &quot;whether the xlator you are associated with works fine if a non-lookup<br>
&gt; &gt; &gt; &gt;&gt; fop (like open, setattr, stat etc) hits it without a lookup ever being<br>
&gt; &gt; &gt; &gt;&gt; done<br>
&gt; &gt; &gt; &gt;&gt; on that inode&quot;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; regards,<br>
&gt; &gt; &gt; &gt;&gt; Raghavendra<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; On Wed, Aug 23, 2017 at 11:56 AM, Raghavendra Gowdappa &lt;<br>
&gt; &gt; &gt; &gt;&gt; <a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; Thanks Pranith and Ashish for your inputs.<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; ----- Original Message -----<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; From: &quot;Pranith Kumar Karampuri&quot; &lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; To: &quot;Ashish Pandey&quot; &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; Cc: &quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;, &quot;Xavier<br>
&gt; &gt; Hernandez&quot; &lt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; <a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt;, &quot;Gluster Devel&quot;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; Sent: Wednesday, August 23, 2017 11:55:19 AM<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; Subject: Re: Need inputs on patch #17985<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; Raghavendra,<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;     As Ashish mentioned, there aren&#39;t any known problems if upper<br>
&gt; &gt; &gt; &gt;&gt;&gt; xlators<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; don&#39;t send lookups in EC at the moment.<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; On Wed, Aug 23, 2017 at 9:07 AM, Ashish Pandey &lt;<br>
&gt; &gt; <a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; Raghvendra,<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; I have provided my comment on this patch.<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; I think EC will not have any issue with this approach.<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; However, I would welcome comments from Xavi and Pranith too for<br>
&gt; &gt; any<br>
&gt; &gt; &gt; &gt;&gt;&gt; side<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; effects which I may not be able to foresee.<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; Ashish<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; ------------------------------<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; *From: *&quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; *To: *&quot;Ashish Pandey&quot; &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; *Cc: *&quot;Pranith Kumar Karampuri&quot; &lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;, &quot;Xavier<br>
&gt; &gt; &gt; &gt;&gt;&gt; Hernandez&quot;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; &lt;<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt;, &quot;Gluster Devel&quot; &lt;<br>
&gt; &gt; <a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; *Sent: *Wednesday, August 23, 2017 8:29:48 AM<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; *Subject: *Need inputs on patch #17985<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; Hi Ashish,<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; Following are the blockers for making a decision on whether patch<br>
&gt; &gt; &gt; &gt;&gt;&gt; [1] can<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; be merged or not:<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; * Evaluation of dentry operations (like rename etc) in dht<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; * Whether EC works fine if a non-lookup fop (like open(dir),<br>
&gt; &gt; stat,<br>
&gt; &gt; &gt; &gt;&gt;&gt; chmod<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; etc) hits EC without a single lookup performed on file/inode<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; Can you please comment on the patch? I&#39;ll take care of dht part.<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; [1] <a href="https://review.gluster.org/#/c/17985/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c<wbr>/17985/</a><br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; regards,<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt; Raghavendra<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; --<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt; Pranith<br>
&gt; &gt; &gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt; &gt; &gt; &gt;&gt;&gt; Gluster-devel mailing list<br>
&gt; &gt; &gt; &gt;&gt;&gt; <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
&gt; &gt; &gt; &gt;&gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; --<br>
&gt; &gt; &gt; &gt;&gt;&gt; Raghavendra G<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; &lt;<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mail<wbr>man/listinfo/gluster-devel</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; ______________________________<wbr>_________________<br>
&gt; &gt; &gt; &gt;&gt; Gluster-devel mailing list<br>
&gt; &gt; &gt; &gt;&gt; <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
&gt; &gt; &gt; &gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt; Raghavendra G<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="m_723269619931310581HOEnZb"><font color="#888888">-- <br><div class="m_723269619931310581m_1623044859594949402gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_723269619931310581gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Milind<br><br></div></div></div></div>
</div>