<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 2:49 PM Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Oct 29, 2018 at 12:06:53PM +0530, Susant Palai wrote:<br>
> On Fri, Oct 26, 2018 at 6:22 PM Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>> wrote:<br>
> <br>
> > On Fri, Oct 26, 2018 at 05:54:28PM +0530, Susant Palai wrote:<br>
> > > Hi,<br>
> > > For ALUA in Gluster-Block, we need fencing support from GlusterFS.<br>
> > This<br>
> > > is targeted mainly to avoid corruption issues during fail-over from<br>
> > > INITIATOR.<br>
> > ><br>
> > > You can find the problem statement, design document at [1] and the GitHub<br>
> > > discussions at [2].<br>
> > ><br>
> > > Requesting your feedback on the same.<br>
> ><br>
> > From a quick glance, this looks very much like leases/delegations that<br>
> > have been added for Samba and NFS-Ganesha. Can you explain why using<br>
> > that is not sufficient?<br>
> ><br>
> Niels, is it that you are suggesting leases/delegations already solves the<br>
> problem we are trying to solve mentioned in the design document or just the<br>
> mandatory lock part?<br>
<br>
I would be interested to know if you can use leases/delegations to solve<br>
the issue. If you can not, can leases/delegations be extended instead of<br>
proposing an new API?<br></blockquote><div><br></div><div>From what I understand Block-D keeps all the file open bfore beginning of the session (exporting file as block devices). Which I guess won't work with lease, since</div><div>lease I guess(please correct me if wrong) breaks the existing lease on an open request. Certainly, with selfheal daemon the lease will be released. Hence, mandatory lock fits here IMO.</div><div><br></div><div><a class="gmail_plusreply" id="plusReplyChip-0" href="mailto:pkalever@redhat.com" tabindex="-1">@Kalever, Prasanna</a> Please give your feedback here.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From theory, the high-available NFS-Ganesha and Samba services should<br>
have solved similar problems already.<br></blockquote><div><br></div><div>From what I understand the multipath layer does not have any control over restarting tcmu-runner on Gluster side (If that is how NFS_Ganesha and Samba provides blacklist for it's clients).</div><div>The targetcli does certain tasks only on failover switch which would be like taking mandatory lock, open a session as mentioned in the design doc. Hence, no control over data cached at Gluster-client layer to be replayed in the event of a disconnection.</div><div><br></div><div>Again <a class="gmail_plusreply" id="plusReplyChip-3" href="mailto:pkalever@redhat.com" tabindex="-1">@Kalever, Prasanna</a> and <a class="gmail_plusreply" id="plusReplyChip-4" href="mailto:xiubli@redhat.com" tabindex="-1">@Xiubo Li</a> will be able to clarify more here.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IIRC Anoop CS And Soumya have been working on this mostly. If you have<br>
specific questions about the implementation in Samba or NFS-Ganesha, ask<br>
on this list and include them on CC.<br>
<br>
Also, we do have the (low-volume) <a href="mailto:integration@gluster.org" target="_blank">integration@gluster.org</a> list for<br>
discussions around integrating gfapi with other projects. There might be<br>
others that are interested in these kind of details.<br>
<br>
Thanks,<br>
Niels<br>
<br>
<br>
> <br>
> ><br>
> > Thanks,<br>
> > Niels<br>
> ><br>
> ><br>
> > ><br>
> > > Thanks,<br>
> > > Susant/Amar/Shyam/Prasanna/Xiubo<br>
> > ><br>
> > ><br>
> > ><br>
> > > [1]<br>
> > ><br>
> > <a href="https://docs.google.com/document/d/1up5egL9SxmVKFpZMUEuuYML6xS2mNmBGzyZbMaw1fl0/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1up5egL9SxmVKFpZMUEuuYML6xS2mNmBGzyZbMaw1fl0/edit?usp=sharing</a><br>
> > > [2]<br>
> > ><br>
> > <a href="https://github.com/gluster/gluster-block/issues/53#issuecomment-432924044" rel="noreferrer" target="_blank">https://github.com/gluster/gluster-block/issues/53#issuecomment-432924044</a><br>
> ><br>
> > > _______________________________________________<br>
> > > Gluster-devel mailing list<br>
> > > <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
> > > <a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
> ><br>
> ><br>
</blockquote></div></div>