Re: on patch #11553

Raghavendra Bhat <rabhat@xxxxxxxxxx> · Wed, 08 Jul 2015 15:40:14 +0530



    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@xxxxxxxxxx> wrote:

          +gluster-devel

            
            ----- Original Message -----

            > From: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>

            > To: "Krishnan Parthasarathi" <kparthas@xxxxxxxxxx>

            > Cc: "Nithya Balachandran" <nbalacha@xxxxxxxxxx>,
            "Anoop C S" <achiraya@xxxxxxxxxx>

            > 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@xxxxxxxxxxx

            http://www.gluster.org/mailman/listinfo/gluster-devel

          
        -- 

        Raghavendra G

        
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel