[Gluster-devel] Please help test Gerrit 2.14
Hello, It's that time again. We need to move up a Gerrit release. Staging has now been upgraded to the latest version. Please help test it and give us feedback on any issues you notice: https://gerrit-stage.rht.gluster.org/ -- nigelb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)
On Sat, Mar 3, 2018 at 12:34 AM, Shyam Ranganathan wrote: > On 03/02/2018 04:24 AM, Kaushal M wrote: >> I was able to create libglusterfsd, with just the pmap_signout nad >> autoscale functions. >> Turned out to be easy enough to do in the end. >> I've pushed a patch for review [1] on master. > > Thanks! > >> >> I've also opened new bugs to track the fixes for master[2] and >> release-4.0[3]. They have been made blockers to the glusterfs-4.0.0 >> tracker bug [4]. >> >> Shyam, >> To backport the fix from master to release-4.0, also requires >> backporting one more change [5]. >> Would you be okay with backporting that as well, in a single patch? > > I am *not* in favor of taking patch [5], it is a feature change, and so > late (considering the current build stability as well, if you are > following other threads). > > Is there a way for your patch to land without the dependency? > The autoscale function had the dependency. But it is trivial to update the patch to move the function, even without the dependency. Later backports from master will be slightly harder though. >> >> [1]: https://review.gluster.org/19657 >> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895 >> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894 >> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842 >> [5]: https://review.gluster.org/19337 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)
On Sat, Mar 3, 2018 at 4:25 AM, Kaleb S. KEITHLEY wrote: > On 03/02/2018 04:24 AM, Kaushal M wrote: >> [snip] >> I was able to create libglusterfsd, with just the pmap_signout nad >> autoscale functions. >> Turned out to be easy enough to do in the end. >> I've pushed a patch for review [1] on master. >> >> I've also opened new bugs to track the fixes for master[2] and >> release-4.0[3]. They have been made blockers to the glusterfs-4.0.0 >> tracker bug [4]. > > I really don't like creating this libglusterfsd.so with just two > functions to get around this. It feels like a quick-and-dirty hack. > (There's never time to do it right, but there's always time to do it > over. Except there isn't.) > > I've posted a change at https://review.gluster.org/19664 that moves > those two functions to libgfrpc.so. It works on my f28/rawhide box and > the various centos and fedora smoke test boxes. No tricky linker flags, > or anything else, required. Regression is running now. > > (And truth be told I'd like to also move glusterfs_mgmt_pmap_signin() > into libgfrpc.so too. Just for (foolish) consistency/symmetry.) Moving a specific RPC client implementation into RPC lib doesn't seem so right to me. But otherwise, this change is okay with me. > >> >> Shyam, >> To backport the fix from master to release-4.0, also requires >> backporting one more change [5]. >> Would you be okay with backporting that as well, in a single patch? >> >> [1]: https://review.gluster.org/19657 >> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895 >> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894 >> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842 >> [5]: https://review.gluster.org/19337 >> > >> >>> >>> -- >>> >>> Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >>> >>> >>> >>> -- >>> Milind >>> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removal of use-compound-fops option in afr
On Mon, Mar 5, 2018 at 9:48 AM, Pranith Kumar Karampuri wrote: > > > On Mon, Mar 5, 2018 at 9:19 AM, Amar Tumballi wrote: > >> Pranith, >> >> >> >>> We found that compound fops is not giving better performance in >>> replicate and I am thinking of removing that code. Sent the patch at >>> https://review.gluster.org/19655 >>> >>> >> If I understand it right, as of now AFR is the only component which uses >> Compound FOP. If it stops using that code, should we maintain the compound >> fop codebase at all in other places, like protocol, volgen (decompounder >> etc?) >> > > Infra was also supposed to be used by gfapi when compound fops is > introduced. So I think it is not a bad idea to keep it until at least there > is a decision about it. It will be similar to loading feature modules like > quota even when quota is not used on the volume. > Got it, makes sense! > > >> >> Because, if AFR as a module decides compound fop is not useful, and other >> method is better, it is completely a decision of AFR maintainers. I don't >> see a concern there. >> >> Only if it had an option and if people are using it, then warning them >> upfront about this change is better. >> > > By default it is off, so I am not expecting it to be in wide use. Even if > they are using it, I don't see any dramatic improvement in their workload > performance based on the numbers we got. This is going to be affective in > 4.1 release. > > I also added gluster-users, so that it is communicated to wider audience. > That's nice! >> Regards, >> Amar >> >> ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removal of use-compound-fops option in afr
On Mon, Mar 5, 2018 at 9:19 AM, Amar Tumballi wrote: > Pranith, > > > >> We found that compound fops is not giving better performance in >> replicate and I am thinking of removing that code. Sent the patch at >> https://review.gluster.org/19655 >> >> > If I understand it right, as of now AFR is the only component which uses > Compound FOP. If it stops using that code, should we maintain the compound > fop codebase at all in other places, like protocol, volgen (decompounder > etc?) > Infra was also supposed to be used by gfapi when compound fops is introduced. So I think it is not a bad idea to keep it until at least there is a decision about it. It will be similar to loading feature modules like quota even when quota is not used on the volume. > > Because, if AFR as a module decides compound fop is not useful, and other > method is better, it is completely a decision of AFR maintainers. I don't > see a concern there. > > Only if it had an option and if people are using it, then warning them > upfront about this change is better. > By default it is off, so I am not expecting it to be in wide use. Even if they are using it, I don't see any dramatic improvement in their workload performance based on the numbers we got. This is going to be affective in 4.1 release. I also added gluster-users, so that it is communicated to wider audience. > > Regards, > Amar > > -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removal of use-compound-fops option in afr
Pranith, > We found that compound fops is not giving better performance in > replicate and I am thinking of removing that code. Sent the patch at > https://review.gluster.org/19655 > > If I understand it right, as of now AFR is the only component which uses Compound FOP. If it stops using that code, should we maintain the compound fop codebase at all in other places, like protocol, volgen (decompounder etc?) Because, if AFR as a module decides compound fop is not useful, and other method is better, it is completely a decision of AFR maintainers. I don't see a concern there. Only if it had an option and if people are using it, then warning them upfront about this change is better. Regards, Amar ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Removal of use-compound-fops option in afr
Shyam, Do let me know if there is anything that needs to be done on the process front. On Mon, Mar 5, 2018 at 8:18 AM, Pranith Kumar Karampuri wrote: > hi, > We found that compound fops is not giving better performance in > replicate and I am thinking of removing that code. Sent the patch at > https://review.gluster.org/19655 > > -- > Pranith > -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Removal of use-compound-fops option in afr
hi, We found that compound fops is not giving better performance in replicate and I am thinking of removing that code. Sent the patch at https://review.gluster.org/19655 -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Weekly Untriaged Bugs
[...truncated 6 lines...] https://bugzilla.redhat.com/1544851 / build: Redefinitions of IXDR_GET_LONG and IXDR_PUT_LONG when libtirpc is used https://bugzilla.redhat.com/1549996 / core: [BMux] : Stale brick processes on the nodes after vol deletion. https://bugzilla.redhat.com/1547888 / core: [brick-mux] incorrect event-thread scaling in server_reconfigure() https://bugzilla.redhat.com/1545142 / core: GlusterFS - Memory Leak during adding directories https://bugzilla.redhat.com/1549473 / core: possible memleak in glusterfsd process with brick multiplexing on https://bugzilla.redhat.com/1547127 / distribute: Typo error in __dht_check_free_space function log message https://bugzilla.redhat.com/1543585 / fuse: Client Memory Usage Drastically Increased from 3.12 to 3.13 for Replicate 3 Volumes https://bugzilla.redhat.com/1542979 / geo-replication: glibc fix for CVE-2018-101 breaks geo-replication https://bugzilla.redhat.com/1546932 / glusterd: systemd units does not stop all gluster daemons https://bugzilla.redhat.com/1548517 / posix: write failed with EINVAL due O_DIRECT write buffer with unaligned size https://bugzilla.redhat.com/1546645 / project-infrastructure: Ansible should setup correct selinux context for /archives https://bugzilla.redhat.com/1545003 / project-infrastructure: Create a new list: automated-test...@gluster.org https://bugzilla.redhat.com/1549662 / project-infrastructure: infra: create nfs-ganesha@ and nfs-ganesha-devel@ https://bugzilla.redhat.com/1547791 / project-infrastructure: Jenkins API error https://bugzilla.redhat.com/1549000 / project-infrastructure: line-coverage tests not capturing details properly. https://bugzilla.redhat.com/1544378 / project-infrastructure: mailman list moderation redirects from https to http https://bugzilla.redhat.com/1545891 / project-infrastructure: Provide a automated way to update bugzilla status with patch merge. https://bugzilla.redhat.com/1550808 / replicate: memory leak in pre-op in replicate volumes for every write https://bugzilla.redhat.com/1550941 / rpc: [brick-mux] performance bottleneck introduced while solving ping timer expiry https://bugzilla.redhat.com/1550946 / rpc: [brick-mux] performance bottleneck introduced while solving ping timer expiry https://bugzilla.redhat.com/1548953 / rpc: Client keeps trying to connect to removed brick https://bugzilla.redhat.com/1546295 / rpc: Official packages don't default to IPv6 https://bugzilla.redhat.com/1542934 / rpc: Seeing timer errors in the rebalance logs https://bugzilla.redhat.com/1542072 / scripts: Syntactical errors in hook scripts for managing SELinux context on bricks #2 (S10selinux-label-brick.sh + S10selinux-del-fcontext.sh) https://bugzilla.redhat.com/1549714 / tiering: On sharded tiered volume, only first shard of new file goes on hot tier. [...truncated 2 lines...] build.log Description: Binary data ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel