[Gluster-devel] on patch #11553

[Raghavendra Bhat]

On 07/07/2015 12:30 PM, Raghavendra G wrote:
> + vijay mallikarjuna for quotad has similar concerns
>
> + Raghavendra Bhat for snapd might've similar concerns.

Snapd also uses protocol/server at the top of the graph. So the fix for 
protocol/server should be good enough.

Regards,
Raghavendra Bhat

>
> On Tue, Jul 7, 2015 at 12:02 PM, Raghavendra Gowdappa 
> <rgowdapp at redhat.com <mailto:rgowdapp at redhat.com>> wrote:
>
>     +gluster-devel
>
>     ----- Original Message -----
>     > From: "Raghavendra Gowdappa" <rgowdapp at redhat.com
>     <mailto:rgowdapp at redhat.com>>
>     > To: "Krishnan Parthasarathi" <kparthas at redhat.com
>     <mailto:kparthas at redhat.com>>
>     > Cc: "Nithya Balachandran" <nbalacha at redhat.com
>     <mailto:nbalacha at redhat.com>>, "Anoop C S" <achiraya at redhat.com
>     <mailto: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 <mailto: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/20150708/ab12b4ed/attachment.html>