[Gluster-devel] Adding ALUA support for Gluster-Block

Susant Palai spalai at redhat.com
Mon Oct 29 10:45:38 UTC 2018


On Mon, Oct 29, 2018 at 2:49 PM Niels de Vos <ndevos at redhat.com> wrote:

> On Mon, Oct 29, 2018 at 12:06:53PM +0530, Susant Palai wrote:
> > On Fri, Oct 26, 2018 at 6:22 PM Niels de Vos <ndevos at redhat.com> wrote:
> >
> > > On Fri, Oct 26, 2018 at 05:54:28PM +0530, Susant Palai wrote:
> > > > Hi,
> > > >    For ALUA in Gluster-Block, we need fencing support from GlusterFS.
> > > This
> > > > is targeted mainly to avoid corruption issues during fail-over from
> > > > INITIATOR.
> > > >
> > > > You can find the problem statement, design document at [1] and the
> GitHub
> > > > discussions at [2].
> > > >
> > > > Requesting your feedback on the same.
> > >
> > > From a quick glance, this looks very much like leases/delegations that
> > > have been added for Samba and NFS-Ganesha. Can you explain why using
> > > that is not sufficient?
> > >
> > Niels, is it that you are suggesting leases/delegations already solves
> the
> > problem we are trying to solve mentioned in the design document or just
> the
> > mandatory lock part?
>
> I would be interested to know if you can use leases/delegations to solve
> the issue. If you can not, can leases/delegations be extended instead of
> proposing an new API?
>

>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
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.

@Kalever, Prasanna <pkalever at redhat.com> Please give your feedback here.


> From theory, the high-available NFS-Ganesha and Samba services should
> have solved similar problems already.
>

>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).
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.

Again @Kalever, Prasanna <pkalever at redhat.com> and @Xiubo Li
<xiubli at redhat.com>  will be able to clarify more here.


> IIRC Anoop CS And Soumya have been working on this mostly. If you have
> specific questions about the implementation in Samba or NFS-Ganesha, ask
> on this list and include them on CC.
>
> Also, we do have the (low-volume) integration at gluster.org list for
> discussions around integrating gfapi with other projects. There might be
> others that are interested in these kind of details.
>
> Thanks,
> Niels
>
>
> >
> > >
> > > Thanks,
> > > Niels
> > >
> > >
> > > >
> > > > Thanks,
> > > > Susant/Amar/Shyam/Prasanna/Xiubo
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> https://docs.google.com/document/d/1up5egL9SxmVKFpZMUEuuYML6xS2mNmBGzyZbMaw1fl0/edit?usp=sharing
> > > > [2]
> > > >
> > >
> https://github.com/gluster/gluster-block/issues/53#issuecomment-432924044
> > >
> > > > _______________________________________________
> > > > Gluster-devel mailing list
> > > > Gluster-devel at gluster.org
> > > > https://lists.gluster.org/mailman/listinfo/gluster-devel
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20181029/e5783043/attachment-0001.html>


More information about the Gluster-devel mailing list