Re: [Gluster-devel] About split-brain-resolution.t
Pranith Kumar Karampuri 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] Responsibilities and expectations of our maintainers
Justin Clift wrote: > Atin has an initial fix for the breakage here: > http://review.gluster.org/#/c/10032/ > Does that help? :) I saw that. Tests running... -- 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
Re: [Gluster-devel] Responsibilities and expectations of our maintainers
On 28 Mar 2015, at 13:12, Emmanuel Dreyfus wrote: > Pranith Kumar Karampuri wrote: > >> By which time some more problems may creep in, it will be chicken and >> egg problem. Force a -2. Everybody will work just on Netbsd for a while >> but after that things should be just similar to Linux. It would probably >> be a good idea to decide a date on which this forcing would happen. > > I will submit a batch of fixes within the next hours. Once they are > merged we will have a sane situation again. > > Except that http://review.gluster.org/10019 causes a few spurious bugs > to become reliable. Once that one is merged, NetBSD regression will be > broken again. Atin has an initial fix for the breakage here: http://review.gluster.org/#/c/10032/ Does that help? :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] About split-brain-resolution.t
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? 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... -- 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
[Gluster-devel] Rackspace NetBSD VM's now rebootable
Hi us, The NetBSD 7 VM's in Rackspace can now be rebooted using Niels' "reboot-vm" job in Jenkins: http://build.gluster.org/job/reboot-vm/ This is useful where the regression runs are acting up on NetBSD, such as when they hang on /opt/qa/build.sh for hours. If that happens to one of you triggered regression runs... (you don't need to wait hours!) please reboot the node and retrigger your regression run. :) Regards and best wishes, Justin Clift -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Responsibilities and expectations of our maintainers
Pranith Kumar Karampuri wrote: > By which time some more problems may creep in, it will be chicken and > egg problem. Force a -2. Everybody will work just on Netbsd for a while > but after that things should be just similar to Linux. It would probably > be a good idea to decide a date on which this forcing would happen. I will submit a batch of fixes within the next hours. Once they are merged we will have a sane situation again. Except that http://review.gluster.org/10019 causes a few spurious bugs to become reliable. Once that one is merged, NetBSD regression will be broken again. -- 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] Responsibilities and expectations of our maintainers
On 03/28/2015 02:08 PM, Emmanuel Dreyfus wrote: Pranith Kumar Karampuri wrote: Emmanuel, What can we do to make it vote -2 when it fails? Things will automatically fall in place if it gives -2. I will do this once I will have recovered. The changelog change broke regression for weeks, and now we have a fix for it I discover many other poblems have crop. By which time some more problems may creep in, it will be chicken and egg problem. Force a -2. Everybody will work just on Netbsd for a while but after that things should be just similar to Linux. It would probably be a good idea to decide a date on which this forcing would happen. Pranith While there, to anyone: - dd bs=1M is not portable. Use dd bs=1024k - echo 3 > /proc/sys/vm/drop_caches is not portable. use instead this command that fails but flushes inodes first. ( cd $M0 && umount $M0 ) - umount $N0 brings many problems, use instead EXPECT_WITHIN $UMOUNT_TIMEOUT "Y" umount_nfs $N0 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Here is why feature/changelog change broke NetBSD
Venky Shankar wrote: > The quickest thing to do is to not spawn the thread (in changelog) > that invokes ->event_dispatch(). This should fix the problem right > away and does not degrade the functionality as the translator stack > already has one running (we'll be just reusing it). Yes, NetBSD passes AFR tests again with that change. I will submit a change for that. What about the same pthread_create in xlators/features/changelog/src/lib/src/gf-changelog.c ? -- 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] Responsibilities and expectations of our maintainers
Pranith Kumar Karampuri wrote: > Emmanuel, > What can we do to make it vote -2 when it fails? Things will > automatically fall in place if it gives -2. I will do this once I will have recovered. The changelog change broke regression for weeks, and now we have a fix for it I discover many other poblems have crop. While there, to anyone: - dd bs=1M is not portable. Use dd bs=1024k - echo 3 > /proc/sys/vm/drop_caches is not portable. use instead this command that fails but flushes inodes first. ( cd $M0 && umount $M0 ) - umount $N0 brings many problems, use instead EXPECT_WITHIN $UMOUNT_TIMEOUT "Y" umount_nfs $N0 -- 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
