<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2016 at 17:21, 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"><div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Xavier Hernandez&quot; &lt;<a href="mailto:xhernandez@datalab.es">xhernandez@datalab.es</a>&gt;<br>
&gt; To: &quot;Raghavendra G&quot; &lt;<a href="mailto:raghavendra@gluster.com">raghavendra@gluster.com</a>&gt;, &quot;Nithya Balachandran&quot; &lt;<a href="mailto:nbalacha@redhat.com">nbalacha@redhat.com</a>&gt;<br>
&gt; Cc: &quot;Gluster Devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>&gt;, &quot;Mohit Agrawal&quot; &lt;<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a>&gt;<br>
&gt; Sent: Thursday, September 15, 2016 4:54:25 PM<br>
&gt; Subject: Re: [Gluster-devel] Query regards to heal xattr heal in dht<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 15/09/16 11:31, Raghavendra G wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Thu, Sep 15, 2016 at 12:02 PM, Nithya Balachandran<br>
&gt; &gt; &lt;<a href="mailto:nbalacha@redhat.com">nbalacha@redhat.com</a> &lt;mailto:<a href="mailto:nbalacha@redhat.com">nbalacha@redhat.com</a>&gt;&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;     On 8 September 2016 at 12:02, Mohit Agrawal &lt;<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a><br>
&gt; &gt;     &lt;mailto:<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a>&gt;&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;         Hi All,<br>
&gt; &gt;<br>
&gt; &gt;            I have one another solution to heal user xattr but before<br>
&gt; &gt;         implement it i would like to discuss with you.<br>
&gt; &gt;<br>
&gt; &gt;            Can i call function (dht_dir_xattr_heal internally it is<br>
&gt; &gt;         calling syncop_setxattr) to heal xattr in dht_getxattr_cbk in last<br>
&gt; &gt;            after make sure we have a valid xattr.<br>
&gt; &gt;            In function(dht_dir_xattr_heal) it will copy blindly all user<br>
&gt; &gt;         xattr on all subvolume or i can compare subvol xattr with valid<br>
&gt; &gt;         xattr if there is any mismatch then i will call syncop_setxattr<br>
&gt; &gt;         otherwise no need to call. syncop_setxattr.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;     This can be problematic if a particular xattr is being removed - it<br>
&gt; &gt;     might still exist on some subvols. IIUC, the heal would go and reset<br>
&gt; &gt;     it again?<br>
&gt; &gt;<br>
&gt; &gt;     One option is to use the hash subvol for the dir as the source - so<br>
&gt; &gt;     perform xattr op on hashed subvol first and on the others only if it<br>
&gt; &gt;     succeeds on the hashed. This does have the problem of being unable<br>
&gt; &gt;     to set xattrs if the hashed subvol is unavailable. This might not be<br>
&gt; &gt;     such a big deal in case of distributed replicate or distribute<br>
&gt; &gt;     disperse volumes but will affect pure distribute. However, this way<br>
&gt; &gt;     we can at least be reasonably certain of the correctness (leaving<br>
&gt; &gt;     rebalance out of the picture).<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; * What is the behavior of getxattr when hashed subvol is down? Should we<br>
&gt; &gt; succeed with values from non-hashed subvols or should we fail getxattr?<br>
&gt; &gt; With hashed-subvol as source of truth, its difficult to determine<br>
&gt; &gt; correctness of xattrs and their values when it is down.<br>
&gt; &gt;<br>
&gt; &gt; * setxattr is an inode operation (as opposed to entry operation). So, we<br>
&gt; &gt; cannot calculate hashed-subvol as in (get)(set)xattr, parent layout and<br>
&gt; &gt; &quot;basename&quot; is not available. This forces us to store hashed subvol in<br>
&gt; &gt; inode-ctx. Now, when the hashed-subvol changes we need to update these<br>
&gt; &gt; inode-ctxs too.<br>
&gt; &gt;<br>
&gt; &gt; What do you think about a Quorum based solution to this problem?<br>
&gt; &gt;<br>
&gt; &gt; 1. setxattr succeeds only if it is successful on at least (n/2 + 1)<br>
&gt; &gt; number of subvols.<br>
&gt; &gt; 2. getxattr succeeds only if it is successful and values match on at<br>
&gt; &gt; least (n/2 + 1) number of subvols.<br>
&gt; &gt;<br>
&gt; &gt; The flip-side of this solution is we are increasing the probability of<br>
&gt; &gt; failure of (get)(set)xattr operations as opposed to the hashed-subvol as<br>
&gt; &gt; source of truth solution. Or are we - how do we compare probability of<br>
&gt; &gt; hashed-subvol going down with probability of (n/2 + 1) nodes going down<br>
&gt; &gt; simultaneously? Is it 1/n vs (1/n*1/n*... (n/2+1 times)?. Is 1/n correct<br>
&gt; &gt; probability for _a specific subvol (hashed-subvol)_ going down (as<br>
&gt; &gt; opposed to _any one subvol_ going down)?<br>
&gt;<br>
&gt; If we suppose p to be the probability of failure of a subvolume in a<br>
&gt; period of time (a year for example), all subvolumes have the same<br>
&gt; probability, and we have N subvolumes, then:<br>
&gt;<br>
&gt; Probability of failure of hashed-subvol: p<br>
&gt; Probability of failure of N/2 + 1 or more subvols: &lt;attached as an image&gt;<br>
<br>
</div></div>Thanks Xavi. That was quick :).<br>
<span class=""><br>
&gt;<br>
&gt; Note that this probability says how much probable is that N/2 + 1<br>
&gt; subvols or more fail in the specified period of time, but not<br>
&gt; necessarily simultaneously. If we suppose that subvolumes are recovered<br>
&gt; as fast as possible, the real probability of simultaneous failure will<br>
&gt; be much smaller.<br>
&gt;<br>
&gt; In worst case (not recovering the failed subvolumes in the given period<br>
&gt; of time), if p &lt; 0.5 or N = 2 (and p != 1), then it&#39;s always better to<br>
&gt; check N/2 + 1 subvolumes. Otherwise, it&#39;s better to check the hashed-subvol.<br>
&gt;<br>
&gt; I think that p should always be much smaller than 0.5 for small periods<br>
&gt; of time where subvolume recovery could no be completed before other<br>
&gt; failures, so checking half plus one subvols should always be the best<br>
&gt; option in terms of probability. Performance can suffer though if some<br>
&gt; kind of synchronization is needed.<br>
<br>
</span>For this problem, no synchronization is needed. We need to wind the (get)(set)xattr call to all subvols though. What I didn&#39;t think through is rollback/rollforward during setxattr if the op fails on more than quorum subvols. One problem with rollback approach is that we may never get a chance to rollback at all and how do we handle racing setxattrs on the same key from different clients/apps (coupled with rollback etc). I need to think more about this.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>A quorum will make it difficult to figure out the correct value in case of in flight modifications/deletions How do you decide the correct value ? This can potentially cause in progress modifications /deletions to be overwritten and to fail silently. The single point of truth (hashed subvol) helps here. Else we will need to bring in some synchronization here.</div><div><br></div><div>I have not looked at the patch yet but how does it currently handle xattr deletes that failed on a subvol?</div><div><br></div><div>A hashed subvol being unavailable should hopefully not be very common esp if there is AFR or EC loaded. A pure distribute volume is expected to have some data unavailability if bricks are unavailable.</div><div><br></div><div>The one case where this could cause major issues as Shyam pointed out is in the case of ACLs /SE linux where the information is stored in xattrs. Something to think about.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
&gt;<br>
&gt; Xavi<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;            Let me know if this approach is suitable.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;         Regards<br>
&gt; &gt;         Mohit Agrawal<br>
&gt; &gt;<br>
&gt; &gt;         On Wed, Sep 7, 2016 at 10:27 PM, Pranith Kumar Karampuri<br>
&gt; &gt;         &lt;<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a> &lt;mailto:<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>&gt;&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;             On Wed, Sep 7, 2016 at 9:46 PM, Mohit Agrawal<br>
&gt; &gt;             &lt;<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a> &lt;mailto:<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a>&gt;&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;                 Hi Pranith,<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;                 In current approach i am getting list of xattr from<br>
&gt; &gt;                 first up volume and update the user attributes from that<br>
&gt; &gt;                 xattr to<br>
&gt; &gt;                 all other volumes.<br>
&gt; &gt;<br>
&gt; &gt;                 I have assumed first up subvol is source and rest of<br>
&gt; &gt;                 them are sink as we are doing same in dht_dir_attr_heal.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;             I think first up subvol is different for different mounts as<br>
&gt; &gt;             per my understanding, I could be wrong.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;                 Regards<br>
&gt; &gt;                 Mohit Agrawal<br>
&gt; &gt;<br>
&gt; &gt;                 On Wed, Sep 7, 2016 at 9:34 PM, Pranith Kumar Karampuri<br>
&gt; &gt;                 &lt;<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a> &lt;mailto:<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>&gt;&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;                     hi Mohit,<br>
&gt; &gt;                            How does dht find which subvolume has the<br>
&gt; &gt;                     correct list of xattrs? i.e. how does it determine<br>
&gt; &gt;                     which subvolume is source and which is sink?<br>
&gt; &gt;<br>
&gt; &gt;                     On Wed, Sep 7, 2016 at 2:35 PM, Mohit Agrawal<br>
&gt; &gt;                     &lt;<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a> &lt;mailto:<a href="mailto:moagrawa@redhat.com">moagrawa@redhat.com</a>&gt;&gt;<br>
&gt; &gt;                     wrote:<br>
&gt; &gt;<br>
&gt; &gt;                         Hi,<br>
&gt; &gt;<br>
&gt; &gt;                           I am trying to find out solution of one<br>
&gt; &gt;                         problem in dht specific to user xattr healing.<br>
&gt; &gt;                           I tried to correct it in a same way as we are<br>
&gt; &gt;                         doing for healing dir attribute but i feel it is<br>
&gt; &gt;                         not best solution.<br>
&gt; &gt;<br>
&gt; &gt;                           To find a right way to heal xattr i want to<br>
&gt; &gt;                         discuss with you if anyone does have better<br>
&gt; &gt;                         solution to correct it.<br>
&gt; &gt;<br>
&gt; &gt;                           Problem:<br>
&gt; &gt;                            In a distributed volume environment custom<br>
&gt; &gt;                         extended attribute value for a directory does<br>
&gt; &gt;                         not display correct value after stop/start the<br>
&gt; &gt;                         brick. If any extended attribute value is set<br>
&gt; &gt;                         for a directory after stop the brick the<br>
&gt; &gt;                         attribute value is not updated on brick after<br>
&gt; &gt;                         start the brick.<br>
&gt; &gt;<br>
&gt; &gt;                           Current approach:<br>
&gt; &gt;                             1) function set_user_xattr to store user<br>
&gt; &gt;                         extended attribute in dictionary<br>
&gt; &gt;                             2) function dht_dir_xattr_heal call<br>
&gt; &gt;                         syncop_setxattr to update the attribute on all<br>
&gt; &gt;                         volume<br>
&gt; &gt;                             3) Call the function (dht_dir_xattr_heal)<br>
&gt; &gt;                         for every directory lookup in<br>
&gt; &gt;                         dht_lookup_revalidate_cbk<br>
&gt; &gt;<br>
&gt; &gt;                           Psuedocode for function dht_dir_xatt_heal is<br>
&gt; &gt;                         like below<br>
&gt; &gt;<br>
&gt; &gt;                            1) First it will fetch atttributes from first<br>
&gt; &gt;                         up volume and store into xattr.<br>
&gt; &gt;                            2) Run loop on all subvolume and fetch<br>
&gt; &gt;                         existing attributes from every volume<br>
&gt; &gt;                            3) Replace user attributes from current<br>
&gt; &gt;                         attributes with xattr user attributes<br>
&gt; &gt;                            4) Set latest extended attributes(current +<br>
&gt; &gt;                         old user attributes) inot subvol.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;                            In this current approach problem is<br>
&gt; &gt;<br>
&gt; &gt;                            1) it will call heal<br>
&gt; &gt;                         function(dht_dir_xattr_heal) for every directory<br>
&gt; &gt;                         lookup without comparing xattr.<br>
&gt; &gt;                             2) The function internally call syncop xattr<br>
&gt; &gt;                         for every subvolume that would be a expensive<br>
&gt; &gt;                         operation.<br>
&gt; &gt;<br>
&gt; &gt;                            I have one another way like below to correct<br>
&gt; &gt;                         it but again in this one it does have dependency<br>
&gt; &gt;                         on time (not sure time is synch on all bricks or<br>
&gt; &gt;                         not)<br>
&gt; &gt;<br>
&gt; &gt;                            1) At the time of set extended<br>
&gt; &gt;                         attribute(setxattr) change time in metadata at<br>
&gt; &gt;                         server side<br>
&gt; &gt;                            2) Compare change time before call healing<br>
&gt; &gt;                         function in dht_revalidate_cbk<br>
&gt; &gt;<br>
&gt; &gt;                             Please share your input on this.<br>
&gt; &gt;                             Appreciate your input.<br>
&gt; &gt;<br>
&gt; &gt;                         Regards<br>
&gt; &gt;                         Mohit Agrawal<br>
&gt; &gt;<br>
&gt; &gt;                         ______________________________<wbr>_________________<br>
&gt; &gt;                         Gluster-devel mailing list<br>
&gt; &gt;                         <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
&gt; &gt;                         &lt;mailto:<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.<wbr>org</a>&gt;<br>
&gt; &gt;                         <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
&gt; &gt;                         &lt;<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><wbr>&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;                     --<br>
&gt; &gt;                     Pranith<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;             --<br>
&gt; &gt;             Pranith<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;         ______________________________<wbr>_________________<br>
&gt; &gt;         Gluster-devel mailing list<br>
&gt; &gt;         <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a> &lt;mailto:<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.<wbr>org</a>&gt;<br>
&gt; &gt;         <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
&gt; &gt;         &lt;<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><wbr>&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;     ______________________________<wbr>_________________<br>
&gt; &gt;     Gluster-devel mailing list<br>
&gt; &gt;     <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a> &lt;mailto:<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.<wbr>org</a>&gt;<br>
&gt; &gt;     <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
&gt; &gt;     &lt;<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><wbr>&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Raghavendra G<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; Gluster-devel mailing list<br>
&gt; &gt; <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
&gt; &gt; <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
&gt; &gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div></div>