Re: [Gluster-devel] GF_FOP_IPC changes
On 06/29/2015 08:18 PM, Niels de Vos wrote: On Wed, Jun 24, 2015 at 07:44:13PM +0530, Soumya Koduri wrote: On 06/24/2015 10:14 AM, Krishnan Parthasarathi wrote: - Original Message - I've been looking at the recent patches to redirect GF_FOP_IPC to an active subvolume instead of always to the first. Specifically, these: http://review.gluster.org/11346 for DHT http://review.gluster.org/11347 for EC http://review.gluster.org/11348 for AFR I can't help but wonder if there's a simpler and more generic way to do this, instead of having to do this in a translator-specific way each time - then again for NSR, or for a separate tiering translator, and so on. For example what if each translator had a first_active_child callback? xlator_t * (*first_active_child) (xlator_t *parent); Then default_ipc could invoke this, if it exists, where it currently invokes FIRST_CHILD. Each translator could implement a bare minimum to select a child, then "step out of the way" for a fop it really wasn't all that interested in to begin with. Any thoughts? We should do this right away. This change doesn't affect external interfaces. we should be bold and implement the first solution. Over time we could improve on this. +1. It would definitely ease the implementation of many such fops which have to default to first active child. We need not keep track of all the fops which may get affected with new clustering xlators being added. I think it is a great improvement and makes the code much easier to understand. Do we have a volunteer that wants to have a go at implementing this? I volunteer. Pranith already seem to have some thoughts on it. I shall check with him and update the initial findings. Thanks, Soumya Thanks, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On Wed, Jun 24, 2015 at 07:44:13PM +0530, Soumya Koduri wrote: > > > On 06/24/2015 10:14 AM, Krishnan Parthasarathi wrote: > > > > > >- Original Message - > >>I've been looking at the recent patches to redirect GF_FOP_IPC to an active > >>subvolume instead of always to the first. Specifically, these: > >> > >>http://review.gluster.org/11346 for DHT > >>http://review.gluster.org/11347 for EC > >>http://review.gluster.org/11348 for AFR > >> > >>I can't help but wonder if there's a simpler and more generic way to do > >>this, > >>instead of having to do this in a translator-specific way each time - then > >>again for NSR, or for a separate tiering translator, and so on. For example > >>what if each translator had a first_active_child callback? > >> > >>xlator_t * (*first_active_child) (xlator_t *parent); > >> > >>Then default_ipc could invoke this, if it exists, where it currently invokes > >>FIRST_CHILD. Each translator could implement a bare minimum to select a > >>child, then "step out of the way" for a fop it really wasn't all that > >>interested in to begin with. Any thoughts? > > > >We should do this right away. This change doesn't affect external interfaces. > >we should be bold and implement the first solution. Over time we could > >improve > >on this. > > +1. It would definitely ease the implementation of many such fops which have > to default to first active child. We need not keep track of all the fops > which may get affected with new clustering xlators being added. I think it is a great improvement and makes the code much easier to understand. Do we have a volunteer that wants to have a go at implementing this? Thanks, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On 06/25/2015 12:10 PM, Soumya Koduri wrote: On 06/25/2015 09:00 AM, Pranith Kumar Karampuri wrote: On 06/25/2015 02:49 AM, Jeff Darcy wrote: It knows which bricks are up/down. But they may not be the latest. Will that matter? AFAIK it's sufficient at this point to know which are up/down. In that case, we need two functions which give first active child and next_active_child in case of failure. Do you suggest then in all default_*_cbk(), on receiving ENOTCONN failure, we re-send fop to next_active_child? Yeah, I think that would be more generic than depending on up-subvols of the cluster xlator. 1) In default_ipc(), wind it to first subvol. 2) If it gives ENOTCONN wind to next child as long as it is not the last child. Pranith Thanks, Soumya Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On 06/25/2015 09:00 AM, Pranith Kumar Karampuri wrote: On 06/25/2015 02:49 AM, Jeff Darcy wrote: It knows which bricks are up/down. But they may not be the latest. Will that matter? AFAIK it's sufficient at this point to know which are up/down. In that case, we need two functions which give first active child and next_active_child in case of failure. Do you suggest then in all default_*_cbk(), on receiving ENOTCONN failure, we re-send fop to next_active_child? Thanks, Soumya Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On 06/25/2015 02:49 AM, Jeff Darcy wrote: It knows which bricks are up/down. But they may not be the latest. Will that matter? AFAIK it's sufficient at this point to know which are up/down. In that case, we need two functions which give first active child and next_active_child in case of failure. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
> It knows which bricks are up/down. But they may not be the latest. Will > that matter? AFAIK it's sufficient at this point to know which are up/down. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On 06/24/2015 08:26 PM, Jeff Darcy wrote: I haven't seen the patches yet. Failures can happen just at the time of winding, leading to same failures. It at least needs to have the logic of picking next_active_child. EC needs to lock+xattrop the bricks to find bricks with good copies. AFR needs to perform getxattr to find good copies. Is that really true? I thought they each had a readily-available idea of which children are up or down, which they already use e.g. for reads. It knows which bricks are up/down. But they may not be the latest. Will that matter? Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
> I haven't seen the patches yet. Failures can happen just at the time of > winding, leading to same failures. It at least needs to have the logic > of picking next_active_child. EC needs to lock+xattrop the bricks to > find bricks with good copies. AFR needs to perform getxattr to find good > copies. Is that really true? I thought they each had a readily-available idea of which children are up or down, which they already use e.g. for reads. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On 06/24/2015 07:44 PM, Soumya Koduri wrote: On 06/24/2015 10:14 AM, Krishnan Parthasarathi wrote: - Original Message - I've been looking at the recent patches to redirect GF_FOP_IPC to an active subvolume instead of always to the first. Specifically, these: http://review.gluster.org/11346 for DHT http://review.gluster.org/11347 for EC http://review.gluster.org/11348 for AFR I can't help but wonder if there's a simpler and more generic way to do this, instead of having to do this in a translator-specific way each time - then again for NSR, or for a separate tiering translator, and so on. For example what if each translator had a first_active_child callback? xlator_t * (*first_active_child) (xlator_t *parent); Then default_ipc could invoke this, if it exists, where it currently invokes FIRST_CHILD. Each translator could implement a bare minimum to select a child, then "step out of the way" for a fop it really wasn't all that interested in to begin with. Any thoughts? We should do this right away. This change doesn't affect external interfaces. we should be bold and implement the first solution. Over time we could improve on this. +1. It would definitely ease the implementation of many such fops which have to default to first active child. We need not keep track of all the fops which may get affected with new clustering xlators being added. I haven't seen the patches yet. Failures can happen just at the time of winding, leading to same failures. It at least needs to have the logic of picking next_active_child. EC needs to lock+xattrop the bricks to find bricks with good copies. AFR needs to perform getxattr to find good copies. Just giving more information to see if it helps. Pranith Thanks, Soumya ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
On 06/24/2015 10:14 AM, Krishnan Parthasarathi wrote: - Original Message - I've been looking at the recent patches to redirect GF_FOP_IPC to an active subvolume instead of always to the first. Specifically, these: http://review.gluster.org/11346 for DHT http://review.gluster.org/11347 for EC http://review.gluster.org/11348 for AFR I can't help but wonder if there's a simpler and more generic way to do this, instead of having to do this in a translator-specific way each time - then again for NSR, or for a separate tiering translator, and so on. For example what if each translator had a first_active_child callback? xlator_t * (*first_active_child) (xlator_t *parent); Then default_ipc could invoke this, if it exists, where it currently invokes FIRST_CHILD. Each translator could implement a bare minimum to select a child, then "step out of the way" for a fop it really wasn't all that interested in to begin with. Any thoughts? We should do this right away. This change doesn't affect external interfaces. we should be bold and implement the first solution. Over time we could improve on this. +1. It would definitely ease the implementation of many such fops which have to default to first active child. We need not keep track of all the fops which may get affected with new clustering xlators being added. Thanks, Soumya ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GF_FOP_IPC changes
- Original Message - > I've been looking at the recent patches to redirect GF_FOP_IPC to an active > subvolume instead of always to the first. Specifically, these: > >http://review.gluster.org/11346 for DHT >http://review.gluster.org/11347 for EC >http://review.gluster.org/11348 for AFR > > I can't help but wonder if there's a simpler and more generic way to do this, > instead of having to do this in a translator-specific way each time - then > again for NSR, or for a separate tiering translator, and so on. For example > what if each translator had a first_active_child callback? > >xlator_t * (*first_active_child) (xlator_t *parent); > > Then default_ipc could invoke this, if it exists, where it currently invokes > FIRST_CHILD. Each translator could implement a bare minimum to select a > child, then "step out of the way" for a fop it really wasn't all that > interested in to begin with. Any thoughts? We should do this right away. This change doesn't affect external interfaces. we should be bold and implement the first solution. Over time we could improve on this. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] GF_FOP_IPC changes
I've been looking at the recent patches to redirect GF_FOP_IPC to an active subvolume instead of always to the first. Specifically, these: http://review.gluster.org/11346 for DHT http://review.gluster.org/11347 for EC http://review.gluster.org/11348 for AFR I can't help but wonder if there's a simpler and more generic way to do this, instead of having to do this in a translator-specific way each time - then again for NSR, or for a separate tiering translator, and so on. For example what if each translator had a first_active_child callback? xlator_t * (*first_active_child) (xlator_t *parent); Then default_ipc could invoke this, if it exists, where it currently invokes FIRST_CHILD. Each translator could implement a bare minimum to select a child, then "step out of the way" for a fop it really wasn't all that interested in to begin with. Any thoughts? ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel