<div dir="ltr"><div style="">I've filed a bug at [1] to track issue in afr.</div><div style=""><br></div>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1341429">https://bugzilla.redhat.com/show_bug.cgi?id=1341429</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 2:17 PM, Raghavendra G <span dir="ltr"><<a href="mailto:raghavendra@gluster.com" target="_blank">raghavendra@gluster.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, May 31, 2016 at 12:37 PM, Xavier Hernandez <span dir="ltr"><<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<span><br>
<br>
On 31/05/16 07:05, Raghavendra Gowdappa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+gluster-devel, +Xavi<br>
<br>
Hi all,<br>
<br>
The context is [1], where bricks do pre-operation checks before doing a fop and proceed with fop only if pre-op check is successful.<br>
<br>
@Xavi,<br>
<br>
We need your inputs on behavior of EC subvolumes as well.<br>
</blockquote>
<br></span>
If I understand correctly, EC shouldn't have any problems here.<br>
<br>
EC sends the mkdir request to all subvolumes that are currently considered "good" and tries to combine the answers. Answers that match in return code, errno (if necessary) and xdata contents (except for some special xattrs that are ignored for combination purposes), are grouped.<br>
<br>
Then it takes the group with more members/answers. If that group has a minimum size of #bricks - redundancy, it is considered the good answer. Otherwise EIO is returned because bricks are in an inconsistent state.<br>
<br>
If there's any answer in another group, it's considered bad and gets marked so that self-heal will repair it using the good information from the majority of bricks.<br>
<br>
xdata is combined and returned even if return code is -1.<br>
<br>
Is that enough to cover the needed behavior ?<br></blockquote><div><br></div></span><div>Thanks Xavi. That's sufficient for the feature in question. One of the main cases I was interested in was what would be the behaviour if mkdir succeeds on "bad" subvolume and fails on "good" subvolume. Since you never wind mkdir to "bad" subvolume(s), this situation never arises.<br><br> <br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Xavi<div><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="http://review.gluster.org/13885" rel="noreferrer" target="_blank">http://review.gluster.org/13885</a><br>
<br>
regards,<br>
Raghavendra<br>
<br>
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: "Pranith Kumar Karampuri" <<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>><br>
To: "Raghavendra Gowdappa" <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>><br>
Cc: "team-quine-afr" <<a href="mailto:team-quine-afr@redhat.com" target="_blank">team-quine-afr@redhat.com</a>>, "rhs-zteam" <<a href="mailto:rhs-zteam@redhat.com" target="_blank">rhs-zteam@redhat.com</a>><br>
Sent: Tuesday, May 31, 2016 10:22:49 AM<br>
Subject: Re: dht mkdir preop check, afr and (non-)readable afr subvols<br>
<br>
I think you should start a discussion on gluster-devel so that Xavi gets a<br>
chance to respond on the mails as well.<br>
<br>
On Tue, May 31, 2016 at 10:21 AM, Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also note that we've plans to extend this pre-op check to all dentry<br>
operations which also depend parent layout. So, the discussion need to<br>
cover all dentry operations like:<br>
<br>
1. create<br>
2. mkdir<br>
3. rmdir<br>
4. mknod<br>
5. symlink<br>
6. unlink<br>
7. rename<br>
<br>
We also plan to have similar checks in lock codepath for directories too<br>
(planning to use hashed-subvolume as lock-subvolume for directories). So,<br>
more fops :)<br>
8. lk (posix locks)<br>
9. inodelk<br>
10. entrylk<br>
<br>
regards,<br>
Raghavendra<br>
<br>
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: "Raghavendra Gowdappa" <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>><br>
To: "team-quine-afr" <<a href="mailto:team-quine-afr@redhat.com" target="_blank">team-quine-afr@redhat.com</a>><br>
Cc: "rhs-zteam" <<a href="mailto:rhs-zteam@redhat.com" target="_blank">rhs-zteam@redhat.com</a>><br>
Sent: Tuesday, May 31, 2016 10:15:04 AM<br>
Subject: dht mkdir preop check, afr and (non-)readable afr subvols<br>
<br>
Hi all,<br>
<br>
I have some queries related to the behavior of afr_mkdir with respect to<br>
readable subvols.<br>
<br>
1. While winding mkdir to subvols does afr check whether the subvolume is<br>
good/readable? Or does it wind to all subvols irrespective of whether a<br>
subvol is good/bad? In the latter case, what if<br>
a. mkdir succeeds on non-readable subvolume<br>
b. fails on readable subvolume<br>
<br>
What is the result reported to higher layers in the above scenario? If<br>
mkdir is failed, is it cleaned up on non-readable subvolume where it<br>
failed?<br>
<br>
I am interested in this case as dht-preop check relies on layout xattrs<br>
</blockquote>
and I<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
assume layout xattrs in particular (and all xattrs in general) are<br>
guaranteed to be correct only on a readable subvolume of afr. So, in<br>
</blockquote>
essence<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
we shouldn't be winding down mkdir on non-readable subvols as whatever<br>
</blockquote>
the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
decision brick makes as part of pre-op check is inherently flawed.<br>
<br>
regards,<br>
Raghavendra<br>
</blockquote></blockquote>
--<br>
Pranith<br>
<br>
</blockquote></blockquote>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature">Raghavendra G<br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</div>