<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 14, 2016 at 12:08 PM, Xavier Hernandez <span dir="ltr">&lt;<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/09/16 21:00, Pranith Kumar Karampuri wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Tue, Sep 13, 2016 at 1:39 PM, Xavier Hernandez &lt;<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a><br></span><div><div class="h5">
&lt;mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt;<wbr>&gt; wrote:<br>
<br>
    Hi Sanoj,<br>
<br>
    On 13/09/16 09:41, Sanoj Unnikrishnan wrote:<br>
<br>
        Hi Xavi,<br>
<br>
        That explains a lot,<br>
        I see a couple of other scenario which can lead to similar<br>
        inconsistency.<br>
        1) simultaneous node/brick crash of 3 bricks.<br>
<br>
<br>
    Although this is a real problem, the 3 bricks should crash exactly<br>
    at the same moment just after having successfully locked the inode<br>
    being modified and queried some information, but before sending the<br>
    write fop nor any down notification. The probability to have this<br>
    suffer this problem is really small.<br>
<br>
        2) if the disk space of underlying filesystem on which brick is<br>
        hosted exceeds for 3 bricks.<br>
<br>
<br>
    Yes. This is the same cause that makes quota fail.<br>
<br>
<br>
        I don&#39;t think we can address all the scenario unless we have a<br>
        log/journal mechanism like raid-5.<br>
<br>
<br>
    I completely agree. I don&#39;t see any solution valid for all cases.<br>
    BTW RAID-5 *is not* a solution. It doesn&#39;t have any log/journal.<br>
    Maybe something based on fdl xlator would work.<br>
<br>
        Should we look at a quota specific fix or let it get fixed<br>
        whenever we introduce a log?<br>
<br>
<br>
    Not sure how to fix this in a way that doesn&#39;t seem too hacky.<br>
<br>
    One possibility is to request permission to write some data before<br>
    actually writing it (specifying offset and size). And then be sure<br>
    that the write will succeed if all (or at least the minimum number<br>
    of data bricks) has acknowledged the previous write permission request.<br>
<br>
    Another approach would be to queue writes in a server side xlator<br>
    until a commit message is received, but sending back an answer<br>
    saying if there&#39;s enough space to do the write (this is, in some<br>
    way, a very primitive log/journal approach).<br>
<br>
    However both approaches will have a big performance impact if they<br>
    cannot be executed in background.<br>
<br>
    Maybe it would be worth investing in fdl instead of trying to find a<br>
    custom solution to this.<br>
<br>
<br>
There are some things we shall do irrespective of this change:<br>
1) When the file is in a state that all 512 bytes of the fragment<br>
represent the data, then we shouldn&#39;t increase the file size at all<br>
which discards the write without any problems, i.e. this case is<br>
recoverable.<br>
</div></div></blockquote>
<br>
I don&#39;t understand this case. You mean a write in an offset smaller than the total size of the file that doesn&#39;t increment it ? if that&#39;s the case, a sparse file could need to allocate new blocks even if the file size doesn&#39;t change.<span class=""><br></span></blockquote><div><br></div><div>I think you got it in the second point, anyways, I was mentioning the same that if the failed write doesn&#39;t touch the previous contents we can keep size as is and not increment the version,size. Example: If the file is 128KB to begin with and we append 4KB and the write fails then we keep the file size as 128KB.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) when we append data to a partially filled chunk and it fails on 3/6<br>
bricks, the rest could be recovered by adjusting the file size to the<br>
size represented by (previous block - 1)*k, we should probably provide<br>
an option to do so?<br>
</blockquote>
<br></span>
We could do that, but this only represents a single case that later will also be covered by the journal.<br>
<br>
In any case, the solution here would be to restore previous file size instead of (previous block - 1) * k, since this can cause the file size to decrease. This works as long as we can assume that a failed write doesn&#39;t touch previous contents.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Proivde some utility/setfattr to perform recovery based on data<br>
rather than versions. i.e. it needs to detect and tell which part of<br>
data is not recoverable and which can be. Based on that, the user should<br>
be able to recover.<br>
</blockquote>
<br></span>
This is not possible with the current implementation, at least in an efficient way. Only way to detect inconsistencies right now would be to create all possible combinations of k bricks and compute the decoded data for each of them. Then check if everything matches. If so, the block is healthy, otherwise there is at least one damaged fragment. Then it would be necessary to find a relation between the fragments used for each reconstruction and the obtained data to determine a probable candidate to be damaged.<br>
<br>
Anyway, if there are 3 bad fragments in a 4+2 configuration, it won&#39;t be possible to recover the data for that block. Of course, in this particular case, this would mean that we would be able to recover all file except the last written block.<br>
<br>
With syndrome decoding (not currently implemented) and using a new encoding matrix, this could be done in an efficient way.<br>
<br>
Xavi<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
What do you guys think?<br>
<br>
<br>
    Xavi<br>
<br>
<br>
<br>
        Thanks and Regards,<br>
        Sanoj<br>
<br>
        ----- Original Message -----<br>
        From: &quot;Xavier Hernandez&quot; &lt;<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a><br></span><span class="">
        &lt;mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt;<wbr>&gt;<br>
        To: &quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a><br></span><span class="">
        &lt;mailto:<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;&gt;, &quot;Sanoj Unnikrishnan&quot;<br>
        &lt;<a href="mailto:sunnikri@redhat.com" target="_blank">sunnikri@redhat.com</a> &lt;mailto:<a href="mailto:sunnikri@redhat.com" target="_blank">sunnikri@redhat.com</a>&gt;&gt;<br>
        Cc: &quot;Pranith Kumar Karampuri&quot; &lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a><br></span><span class="">
        &lt;mailto:<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;&gt;, &quot;Ashish Pandey&quot;<br>
        &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a> &lt;mailto:<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;&gt;, &quot;Gluster<br>
        Devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a><br></span>
        &lt;mailto:<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.<wbr>org</a>&gt;&gt;<div><div class="h5"><br>
        Sent: Tuesday, September 13, 2016 11:50:27 AM<br>
        Subject: Re: Need help with<br>
        <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224180" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1224180</a><br>
        &lt;<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224180" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/s<wbr>how_bug.cgi?id=1224180</a>&gt;<br>
<br>
        Hi Sanoj,<br>
<br>
        I&#39;m unable to see bug 1224180. Access is restricted.<br>
<br>
        Not sure what is the problem exactly, but I see that quota is<br>
        involved.<br>
        Currently disperse doesn&#39;t play well with quota when the limit<br>
        is near.<br>
<br>
        The reason is that not all bricks fail at the same time with<br>
        EDQUOT due<br>
        to small differences is computed space. This causes a valid write to<br>
        succeed on some bricks and fail on others. If it fails<br>
        simultaneously on<br>
        more than redundancy bricks but less that the number of data bricks,<br>
        there&#39;s no way to rollback the changes on the bricks that have<br>
        succeeded, so the operation is inconsistent and an I/O error is<br>
        returned.<br>
<br>
        For example, on a 6:2 configuration (4 data bricks and 2<br>
        redundancy), if<br>
        3 bricks succeed and 3 fail, there are not enough bricks with the<br>
        updated version, but there aren&#39;t enough bricks with the old<br>
        version either.<br>
<br>
        If you force 2 bricks to be down, the problem can appear more<br>
        frequently<br>
        as only a single failure causes this problem.<br>
<br>
        Xavi<br>
<br>
        On 13/09/16 06:09, Raghavendra Gowdappa wrote:<br>
<br>
            +gluster-devel<br>
<br>
            ----- Original Message -----<br>
<br>
                From: &quot;Sanoj Unnikrishnan&quot; &lt;<a href="mailto:sunnikri@redhat.com" target="_blank">sunnikri@redhat.com</a><br></div></div>
                &lt;mailto:<a href="mailto:sunnikri@redhat.com" target="_blank">sunnikri@redhat.com</a>&gt;&gt;<span class=""><br>
                To: &quot;Pranith Kumar Karampuri&quot; &lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a><br></span>
                &lt;mailto:<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;&gt;, &quot;Ashish Pandey&quot;<br>
                &lt;<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a> &lt;mailto:<a href="mailto:aspandey@redhat.com" target="_blank">aspandey@redhat.com</a>&gt;&gt;,<br>
                <a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a> &lt;mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>&gt;<wbr>,<br>
                &quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a><br>
                &lt;mailto:<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>&gt;&gt;<div><div class="h5"><br>
                Sent: Monday, September 12, 2016 7:06:59 PM<br>
                Subject: Need help with<br>
                <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224180" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1224180</a><br>
                &lt;<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224180" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/s<wbr>how_bug.cgi?id=1224180</a>&gt;<br>
<br>
                Hello Xavi/Pranith,<br>
<br>
                I have been able to reproduce the BZ with the following<br>
                steps:<br>
<br>
                gluster volume create v_disp disperse 6 redundancy 2<br>
                $tm1:/export/sdb/br1<br>
                $tm2:/export/sdb/b2 $tm3:/export/sdb/br3<br>
                $tm1:/export/sdb/b4<br>
                $tm2:/export/sdb/b5 $tm3:/export/sdb/b6 force<br>
                #(Used only 3 nodes, should not matter here)<br>
                gluster volume start v_disp<br>
                mount -t glusterfs $tm1:v_disp /gluster_vols/v_disp<br>
                mkdir /gluster_vols/v_disp/dir1<br>
                dd if=/dev/zero of=/gluster_vols/v_disp/dir1/x bs=10k<br>
                count=90000 &amp;<br>
                gluster v quota v_disp enable<br>
                gluster v quota v_disp limit-usage /dir1 200MB<br>
                gluster v quota v_disp soft-timeout 0<br>
                gluster v quota v_disp hard-timeout 0<br>
                #optional remove 2 bricks (reproduces more often with this)<br>
                #pgrep glusterfsd | xargs kill -9<br>
<br>
                IO error on stdout when Quota exceeds, followed by Disk<br>
                Quota exceeded.<br>
<br>
                Also note the issue is seen when A flush happens<br>
                simultaneous with quota<br>
                limit hit, Hence Its not seen only on some runs.<br>
<br>
                The following are the error in logs.<br>
                [2016-09-12 10:40:02.431568] E [MSGID: 122034]<br>
                [ec-common.c:488:ec_child_sele<wbr>ct] 0-v_disp-disperse-0:<br>
                Insufficient<br>
                available childs for this request (have 0, need 4)<br>
                [2016-09-12 10:40:02.431627] E [MSGID: 122037]<br>
                [ec-common.c:1830:ec_update_si<wbr>ze_version_done]<br>
                0-Disperse: sku-debug:<br>
                pre-version=0/0, size=0post-version=1865/1865,<br>
                size=209571840<br>
                [2016-09-12 10:40:02.431637] E [MSGID: 122037]<br>
                [ec-common.c:1835:ec_update_si<wbr>ze_version_done]<br>
                0-v_disp-disperse-0: Failed<br>
                to update version and size [Input/output error]<br>
                [2016-09-12 10:40:02.431664] E [MSGID: 122034]<br>
                [ec-common.c:417:ec_child_sele<wbr>ct] 0-v_disp-disperse-0:<br>
                sku-debug: mask: 36,<br>
                ec-&gt;xl_up 36, ec-&gt;node_mask 3f, parent-&gt;mask:36,<br>
                fop-&gt;parent-&gt;healing:0,<br>
                id:29<br>
<br>
                [2016-09-12 10:40:02.431673] E [MSGID: 122034]<br>
                [ec-common.c:480:ec_child_sele<wbr>ct] 0-v_disp-disperse-0:<br>
                sku-debug: mask: 36,<br>
                remaining: 36, healing: 0, ec-&gt;xl_up 36, ec-&gt;node_mask<br>
                3f, parent-&gt;mask:36,<br>
                num:4, minimum: 1, id:29<br>
<br>
                ...<br>
                [2016-09-12 10:40:02.487302] W<br>
                [fuse-bridge.c:2311:fuse_write<wbr>v_cbk]<br>
                0-glusterfs-fuse: 41159: WRITE =&gt; -1<br>
                gfid=ee0b4aa1-1f44-486a-883c-a<wbr>cddc13ee318<br>
                fd=0x7f1d9c003edc (Input/output<br>
                error)<br>
                [2016-09-12 10:40:02.500151] W [MSGID: 122006]<br>
                [ec-combine.c:206:ec_iatt_comb<wbr>ine] 0-v_disp-disperse-0:<br>
                Failed to combine<br>
                iatt (inode: 9816911356190712600-9816911356<wbr>190712600,<br>
                links: 1-1, uid: 0-0,<br>
                gid: 0-0, rdev: 0-0, size: 52423680-52413440, mode:<br>
                100644-100644)<br>
                [2016-09-12 10:40:02.500188] N [MSGID: 122029]<br>
                [ec-combine.c:93:ec_combine_wr<wbr>ite] 0-v_disp-disperse-0:<br>
                Mismatching iatt in<br>
                answers of &#39;WRITE&#39;<br>
                [2016-09-12 10:40:02.504551] W [MSGID: 122006]<br>
                [ec-combine.c:206:ec_iatt_comb<wbr>ine] 0-v_disp-disperse-0:<br>
                Failed to combine<br>
                iatt (inode: 9816911356190712600-9816911356<wbr>190712600,<br>
                links: 1-1, uid: 0-0,<br>
                gid: 0-0, rdev: 0-0, size: 52423680-52413440, mode:<br>
                100644-100644)<br>
                ....<br>
                ....<br>
<br>
                [2016-09-12 10:40:02.571272] N [MSGID: 122029]<br>
                [ec-combine.c:93:ec_combine_wr<wbr>ite] 0-v_disp-disperse-0:<br>
                Mismatching iatt in<br>
                answers of &#39;WRITE&#39;<br>
                [2016-09-12 10:40:02.571510] W [MSGID: 122006]<br>
                [ec-combine.c:206:ec_iatt_comb<wbr>ine] 0-v_disp-disperse-0:<br>
                Failed to combine<br>
                iatt (inode: 9816911356190712600-9816911356<wbr>190712600,<br>
                links: 1-1, uid: 0-0,<br>
                gid: 0-0, rdev: 0-0, size: 52423680-52413440, mode:<br>
                100644-100644)<br>
                [2016-09-12 10:40:02.571544] N [MSGID: 122029]<br>
                [ec-combine.c:93:ec_combine_wr<wbr>ite] 0-v_disp-disperse-0:<br>
                Mismatching iatt in<br>
                answers of &#39;WRITE&#39;<br>
                [2016-09-12 10:40:02.571772] W<br>
                [fuse-bridge.c:1290:fuse_err_c<wbr>bk]<br>
                0-glusterfs-fuse: 41160: FLUSH() ERR =&gt; -1 (Input/output<br>
                error)<br>
<br>
                Also, for some fops before the write I noticed the<br>
                fop-&gt;mask field as 0, Its<br>
                not clear why this happens ??<br>
<br>
                [2016-09-12 10:40:02.431561] E [MSGID: 122034]<br>
                [ec-common.c:480:ec_child_sele<wbr>ct] 0-v_disp-disperse-0:<br>
                sku-debug: mask: 0,<br>
                remaining: 0, healing: 0, ec-&gt;xl_up 36, ec-&gt;node_mask<br>
                3f, parent-&gt;mask:36,<br>
                num:0, minimum: 4, fop-&gt;id:34<br>
                [2016-09-12 10:40:02.431568] E [MSGID: 122034]<br>
                [ec-common.c:488:ec_child_sele<wbr>ct] 0-v_disp-disperse-0:<br>
                Insufficient<br>
                available childs for this request (have 0, need 4)<br>
                [2016-09-12 10:40:02.431637] E [MSGID: 122037]<br>
                [ec-common.c:1835:ec_update_si<wbr>ze_version_done]<br>
                0-v_disp-disperse-0: Failed<br>
                to update version and size [Input/output error]<br>
<br>
                Is the zero value of fop-&gt;mask related to mismatch in iatt ?<br>
                Any scenario of race between write/flush fop?<br>
                please suggest how to proceed.<br>
<br>
                Thanks and Regards,<br>
                Sanoj<br>
<br>
<br>
<br>
<br>
--<br>
Pranith<br>
</div></div></blockquote>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>