Re: [Gluster-devel] About split-brain-resolution.t
- Original Message - From: Emmanuel Dreyfus m...@netbsd.org To: Anuradha Talur ata...@redhat.com, Pranith Kumar Karampuri pkara...@redhat.com Cc: gluster-devel@gluster.org Sent: Tuesday, March 31, 2015 9:55:24 PM Subject: Re: [Gluster-devel] About split-brain-resolution.t Anuradha Talur ata...@redhat.com wrote: 1) I send a patch today to revert the .t and send it again along with the fix. Or... 2) Can this be failure be ignored till the fix is merged in? We can ignore: NetBSD regresssion skips the test for now. Hi, I've sent a patch to fix this issue, it is currently being reviewed : http://review.gluster.org/#/c/10134/ . -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org -- Thanks, Anuradha. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About split-brain-resolution.t
Anuradha Talur ata...@redhat.com wrote: 1) I send a patch today to revert the .t and send it again along with the fix. Or... 2) Can this be failure be ignored till the fix is merged in? We can ignore: NetBSD regresssion skips the test for now. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About split-brain-resolution.t
On 03/30/2015 06:01 PM, Emmanuel Dreyfus wrote: On Mon, Mar 30, 2015 at 05:44:23PM +0530, Pranith Kumar Karampuri wrote: Problem here is that ' inode_forget' is coming even before it gets to inspect the file. We initially thought we should 'ref' the inode when the user specifies the choice and 'unref' it at the time of 'finalize' or 'abort' of the operation. But that may lead to un-necessary leaks when the user forgets to do either finalize/abort the operation. One way to get around it is to ref the inode for some 'pre-determined time' when 'choice' is given. That suggests the design is not finalized ans the implementation ought to have unwanted behaviors. IMO the test should be retired until the design and implementation is completed. I will work with Anuradha tomorrow about this one and either send a patch to remove the .t file or send the fix which makes things right. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About split-brain-resolution.t
On 03/30/2015 06:34 PM, Emmanuel Dreyfus wrote: Pranith Kumar Karampuri pkara...@redhat.com wrote: Since spb_choice is not saved as an attribute for the file on the bricks, it cannot be recovered when the context is reallocated. Either that save feature has been forgotten, or going to afr_destroy() here is a bug. Here is the backtrace leading there: This is a known issue :-(. I will need to talk to Anuradha once about this issue. She is not in today. Will let you know about the decision. It seems the thing arise because a threads quits and decide to cleanup stuff. Do we have an idea what this thread is? For the test to pass we need to keep the thread alive. Of course that works around a real problem. Why don't we immediatly clear pending xattr when replica.split-brain-choice is set? That would clear the split brain state. this is how the feature is supposed to work: https://github.com/gluster/glusterfs/blob/master/doc/features/heal-info-and-split-brain-resolution.md Basically the choice is given to inspect the 'data' of the file. Then one can finalize the choice which will clear the pending xattrs after resolving the split-brain. Problem here is that ' inode_forget' is coming even before it gets to inspect the file. We initially thought we should 'ref' the inode when the user specifies the choice and 'unref' it at the time of 'finalize' or 'abort' of the operation. But that may lead to un-necessary leaks when the user forgets to do either finalize/abort the operation. One way to get around it is to ref the inode for some 'pre-determined time' when 'choice' is given. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About split-brain-resolution.t
Pranith Kumar Karampuri pkara...@redhat.com wrote: I see split-brain-resolution.t uses attribute replica.split-brain-choice to choose what replica should be used. This attribute is not in privilegied space (trusted. prefixed). Is it on purpose? Yes, these are used as internal commands to make a choice when file is in split-brain. Sure, but since it is not privilegied namespace, it means unprivilegied user can fiddle with it. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About split-brain-resolution.t
On 03/28/2015 09:51 PM, Emmanuel Dreyfus wrote: Hi I see split-brain-resolution.t uses attribute replica.split-brain-choice to choose what replica should be used. This attribute is not in privilegied space (trusted. prefixed). Is it on purpose? Yes, these are used as internal commands to make a choice when file is in split-brain. While there, just in case someone has an idea on this: on NetBSD setting this attribute is ignored. The brick gets some request but does not set the attribute. Not yet investigated, but just in case someone has an idea... Yes it is treated as command and not set on the file. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
