[Gluster-devel] on patch #11553

Raghavendra G raghavendra at gluster.com
Tue Jul 7 07:00:09 UTC 2015


+ vijay mallikarjuna for quotad has similar concerns

+ Raghavendra Bhat for snapd might've similar concerns.

On Tue, Jul 7, 2015 at 12:02 PM, Raghavendra Gowdappa <rgowdapp at redhat.com>
wrote:

> +gluster-devel
>
> ----- Original Message -----
> > From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> > To: "Krishnan Parthasarathi" <kparthas at redhat.com>
> > Cc: "Nithya Balachandran" <nbalacha at redhat.com>, "Anoop C S" <
> achiraya at redhat.com>
> > Sent: Tuesday, 7 July, 2015 11:32:01 AM
> > Subject: on patch #11553
> >
> > KP,
> >
> > Though the crash because of lack of init while fops are in progress is
> > solved, concerns addressed by [1] are still valid. Basically what we
> need to
> > guarantee is that when is it safe to wind fops through a particular
> subvol
> > of protocol/server. So, if some xlators are doing things in events like
> > CHILD_UP (like trash), server_setvolume should wait for CHILD_UP on a
> > particular subvol before accepting a client. So, [1] is necessary but
> > following changes need to be made:
> >
> > 1. protocol/server _can_ have multiple subvol as children. In that case
> we
> > should track whether the exported subvol has received CHILD_UP and only
> > after a successful CHILD_UP on that subvol connections to that subvol
> can be
> > accepted.
> > 2. It is valid (though not a common thing on brick process) that some
> subvols
> > can be up and some might be down. So, child readiness should be
> localised to
> > that subvol instead of tracking readiness at protocol/server level.
> >
> > So, please revive [1] and send it with corrections and I'll merge it.
> >
> > [1] http://review.gluster.org/11553
> >
> > regards,
> > Raghavendra.
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150707/c595f757/attachment.html>


More information about the Gluster-devel mailing list