Re: [Gluster-devel] submitted but merge pending issue seems to be back :-(
On 02/02/2015 09:14 PM, Vijay Bellur wrote: On 02/02/2015 01:37 PM, Niels de Vos wrote: On Mon, Feb 02, 2015 at 05:47:31PM +0530, Pranith Kumar Karampuri wrote: I see the following two patches in that state: http://review.gluster.com/9456 http://review.gluster.com/9409 http://review.gluster.com/#/q/status:submitted,n,z has a list of all of them :-/ http://review.gluster.com/9518 seems to be stuck in a loop or something? Please have a look at https://bugzilla.redhat.com/show_bug.cgi?id=1146985#c1 for fixing the issue. This issue seemed to be a different one. Noticed the following error in the logs: org.eclipse.jgit.errors.ObjectWritingException: Unable to create new object: Upon checking, I saw there were some permission problems on the glusterfs.git repository. I performed a recursive chown of glusterfs.git to review:gerrit2. It seems to be fixed now as a patch got merged after the chown. I had to abandon a few patches before doing the recursive chown. Apologies for that. Please re-submit all abandoned patches and we'll ensure that they get merged on priority. Update: I revived all patches that had been abandoned due to the gerrit problem and have merged them. Can owners of these patches please verify that all is in order now? Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] submitted but merge pending issue seems to be back :-(
On 02/02/2015 01:37 PM, Niels de Vos wrote: On Mon, Feb 02, 2015 at 05:47:31PM +0530, Pranith Kumar Karampuri wrote: I see the following two patches in that state: http://review.gluster.com/9456 http://review.gluster.com/9409 http://review.gluster.com/#/q/status:submitted,n,z has a list of all of them :-/ http://review.gluster.com/9518 seems to be stuck in a loop or something? Please have a look at https://bugzilla.redhat.com/show_bug.cgi?id=1146985#c1 for fixing the issue. This issue seemed to be a different one. Noticed the following error in the logs: org.eclipse.jgit.errors.ObjectWritingException: Unable to create new object: Upon checking, I saw there were some permission problems on the glusterfs.git repository. I performed a recursive chown of glusterfs.git to review:gerrit2. It seems to be fixed now as a patch got merged after the chown. I had to abandon a few patches before doing the recursive chown. Apologies for that. Please re-submit all abandoned patches and we'll ensure that they get merged on priority. Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Integrating liburcu source into the glusterfs source tree
I'm currently testing my changes with liburcu-0.7.* . It is missing just one API which I'm using from 0.8. I've written a local implementation of just that one function, and am currently in process of testing this. If this test is successful, then our problems will be minimized. This only leaves out Debian Wheezy and Ubuntu Precise with liburcu-0.6.* . I tried testing this out, but as liburcu-0.6 doesn't apparently provide pkg-config configurations, I stopped as soon as I started. ~kaushal On Mon, Feb 2, 2015 at 2:37 PM, Niels de Vos nde...@redhat.com wrote: On Mon, Feb 02, 2015 at 09:10:36AM +0530, Kaushal M wrote: Thanks for this information Kaleb. I'll check the changes I've done till now with the older versions of the libraries. I think I'm going to need at least the 0.8.* release of liburcu, as some new apis were introduced in it, which I'm using. I'll post the outcome of my tests back here. For a start, I collected the various versions of liburcu (userspace-rcu in some) available in the different distros. This list is based on the distros for which we provide community built packages and test on. - Fedora 21 - 0.8.1 (0.8.5 in testing but stuck due to some breakages) - Fedora 20 - 0.7.7 (0.8.5 in testing but stuck due to some breakages) - EL7 - 0.7.9 - EL6 - 0.7.7 - Debian Wheezy - 0.6.7 - Debian Jessie - 0.8.5 (in testing) - Ubuntu Precise - 0.6.7 - Ubuntu Trusty - 0.7.12 - Ubuntu Utopic - 0.8.4 - Netbsd - 0.8.6 - Freebsd - 0.7.7 The list doesn't look too good. I do not like including libraries in the glusterfs sources. Currently there are several bits under contrib/ that do not see any maintenance. Who will be maintaining (fixing potential bugs, backporting newer versions, ...) for linurcu? Note that we support *many* different distributions, architectures and master+3 releases. It would be *so* much more efficient to use the distributions version of liburcu. Maybe it is possible to write some wrapper functions for the older versions of the library, and place those wrappers in contrib/ instead? Alternatively, we could maintain packages for liburcu in our repositories on download.gluster.org for distributions that do not have a recent enough version. You will need to find a relyable packager that agrees to take on this task. Niels ~kaushal On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote: Hi, Just FYI, what you propose is called bundling in Fedora packaging parlance, and Fedora's packaging guidelines forbid bundling. It is possible to get an exception granted, but it's not safe to presume that an exception will be granted. (For downstream this is a non-issue, but here on gluster-devel we're not concerned with downstream.) You either need to convince the maintainers of liburcu to update to the newer versions everywhere, or you need to implement using the oldest version on the platforms you intend to support. And if this is too onerous, e.g. to use what's in (RH)EL5, then it's another argument in favor of dropping support for (RH)EL5. (The other argument is that python on RHEL5 is too old for geo-rep.) In short, those of use who package gluster in Fedora would be, however reluctantly, required to vote against doing this. I recommend contacting the liburcu maintainers in Fedora/EPEL and see if you can't convince them to update to the newest version. Regards, -- Kaleb /30/2015 12:09 PM, Deepak Shetty wrote: On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M kshlms...@gmail.com mailto:kshlms...@gmail.com wrote: Hi all, I had started a thread previously on the efforts we are undertaking to improve thread synchronization in GlusterD [1]. I had mentioned that we will be using RCU for synchronization and the userspace RCU library (liburcu) [2] for implementation. I am now in a almost in a position to submit changes to Gerrit for review. But, I have an obstacle of making liburcu available on the jenkins slaves. I have begun development using the 0.8.6 version of liburcu, which is the latest stable release. EPEL has liburcu packages for CentOS 6 and 7, but they are the of the older 0.7.* versions. Fedora has packages more recent packages, but they are still older, 0.8.1. [3]. Considering the above situation with binary packages, I'm considering adding liburcu into the GlusterFS tree as a part of /contrib. This will be similar in vein to the argp-standalone library. liburcu is licensed under LGPL-v2.1, so I don't think there is going to be any problem including it. But IANAL, so I would like to know of if this would if this is okay from a legal perspective. I'll add the liburcu source to our tree and push the change for review. I'm not
Re: [Gluster-devel] submitted but merge pending issue seems to be back :-(
On Mon, Feb 02, 2015 at 05:47:31PM +0530, Pranith Kumar Karampuri wrote: I see the following two patches in that state: http://review.gluster.com/9456 http://review.gluster.com/9409 http://review.gluster.com/#/q/status:submitted,n,z has a list of all of them :-/ http://review.gluster.com/9518 seems to be stuck in a loop or something? Please have a look at https://bugzilla.redhat.com/show_bug.cgi?id=1146985#c1 for fixing the issue. Who said a Gerrit update was overdue? Niels pgpM69aSItBbk.pgp Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Integrating liburcu source into the glusterfs source tree
The local implementation is working well for liburcu-0.7. I'll be continuing with this approach as it is going to cover most of the systems we target. We can decide how we'll handle Debian Wheezy and Ubuntu Precise later. ~kaushal On Mon, Feb 2, 2015 at 3:00 PM, Kaushal M kshlms...@gmail.com wrote: I'm currently testing my changes with liburcu-0.7.* . It is missing just one API which I'm using from 0.8. I've written a local implementation of just that one function, and am currently in process of testing this. If this test is successful, then our problems will be minimized. This only leaves out Debian Wheezy and Ubuntu Precise with liburcu-0.6.* . I tried testing this out, but as liburcu-0.6 doesn't apparently provide pkg-config configurations, I stopped as soon as I started. ~kaushal On Mon, Feb 2, 2015 at 2:37 PM, Niels de Vos nde...@redhat.com wrote: On Mon, Feb 02, 2015 at 09:10:36AM +0530, Kaushal M wrote: Thanks for this information Kaleb. I'll check the changes I've done till now with the older versions of the libraries. I think I'm going to need at least the 0.8.* release of liburcu, as some new apis were introduced in it, which I'm using. I'll post the outcome of my tests back here. For a start, I collected the various versions of liburcu (userspace-rcu in some) available in the different distros. This list is based on the distros for which we provide community built packages and test on. - Fedora 21 - 0.8.1 (0.8.5 in testing but stuck due to some breakages) - Fedora 20 - 0.7.7 (0.8.5 in testing but stuck due to some breakages) - EL7 - 0.7.9 - EL6 - 0.7.7 - Debian Wheezy - 0.6.7 - Debian Jessie - 0.8.5 (in testing) - Ubuntu Precise - 0.6.7 - Ubuntu Trusty - 0.7.12 - Ubuntu Utopic - 0.8.4 - Netbsd - 0.8.6 - Freebsd - 0.7.7 The list doesn't look too good. I do not like including libraries in the glusterfs sources. Currently there are several bits under contrib/ that do not see any maintenance. Who will be maintaining (fixing potential bugs, backporting newer versions, ...) for linurcu? Note that we support *many* different distributions, architectures and master+3 releases. It would be *so* much more efficient to use the distributions version of liburcu. Maybe it is possible to write some wrapper functions for the older versions of the library, and place those wrappers in contrib/ instead? Alternatively, we could maintain packages for liburcu in our repositories on download.gluster.org for distributions that do not have a recent enough version. You will need to find a relyable packager that agrees to take on this task. Niels ~kaushal On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote: Hi, Just FYI, what you propose is called bundling in Fedora packaging parlance, and Fedora's packaging guidelines forbid bundling. It is possible to get an exception granted, but it's not safe to presume that an exception will be granted. (For downstream this is a non-issue, but here on gluster-devel we're not concerned with downstream.) You either need to convince the maintainers of liburcu to update to the newer versions everywhere, or you need to implement using the oldest version on the platforms you intend to support. And if this is too onerous, e.g. to use what's in (RH)EL5, then it's another argument in favor of dropping support for (RH)EL5. (The other argument is that python on RHEL5 is too old for geo-rep.) In short, those of use who package gluster in Fedora would be, however reluctantly, required to vote against doing this. I recommend contacting the liburcu maintainers in Fedora/EPEL and see if you can't convince them to update to the newest version. Regards, -- Kaleb /30/2015 12:09 PM, Deepak Shetty wrote: On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M kshlms...@gmail.com mailto:kshlms...@gmail.com wrote: Hi all, I had started a thread previously on the efforts we are undertaking to improve thread synchronization in GlusterD [1]. I had mentioned that we will be using RCU for synchronization and the userspace RCU library (liburcu) [2] for implementation. I am now in a almost in a position to submit changes to Gerrit for review. But, I have an obstacle of making liburcu available on the jenkins slaves. I have begun development using the 0.8.6 version of liburcu, which is the latest stable release. EPEL has liburcu packages for CentOS 6 and 7, but they are the of the older 0.7.* versions. Fedora has packages more recent packages, but they are still older, 0.8.1. [3]. Considering the above situation with binary packages, I'm considering adding liburcu into the GlusterFS tree as a part of /contrib. This will be similar in vein to the argp-standalone library.
Re: [Gluster-devel] [Gluster-infra] Possibility to move our Jenkins setup to the CentOS Jenkins infra
On Sat, Jan 31, 2015 at 07:43:39AM -0500, Justin Clift wrote: Hi all, One of the things which has been a fair drag for the developer part of the Gluster Community, is maintaining our own Jenkins infrastructure. When chatting with the CentOS guys (pre-FOSDEM) the other day, there is the possibility we could use their Jenkins infrastructure instead. They have a *bunch* of physical nodes (100+), and several other projects are using it as well (Ceph, and others). This would potentially make things easier for us, and they're not limited to running things on CentOS either. They already have FreeBSD nodes, and don't foresee problems with getting NetBSD up and running. At the moment, I'm kind of having the opinion this could be a good way forward, and we should probably try out our smoke/regression scripting on their setup to see if it's workable. And if it turns out to be, then great, and we migrate all of our jenkins there then decommission ours (including the master. :) What do people reckon? Sounds good to me in general. Is there a document that describes their Jenkins setupi (like provisioning of the slaves)? Note that we do not (yet) have a way of automated multi-host tests in Jenkins, but that should be looked into one day. Also, is it possible for Gluster Community members to log into a Jenkins slave and troubleshoot specific failures? Thanks, Niels pgpKxkJHtu_71.pgp Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] GFID to Path Conversion if Historical Changelogs available
Hi, While discussing about the possible options to convert from GFID to path, Venky suggested to search in Historical GlusterFS Changelogs and get the information about Parent GFID and basename of the file. This method works well for FOPs except Rename and Hard links. Approach: - Will consider b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 as GFID for all illustrations and file name as file1 1. If .glusterfs/b6/7b/b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 is Symlink, Readlink and Convert to relative path and Print(Easy conversion, done :)) 2. If not Symlink, Stat on file .glusterfs/b6/7b/b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 and get st_ctime(For example ctime is 1422694569) 3. Search for CHANGELOG.1422694565, CHANGELOG.1422694566.. CHANGELOG.1422694590. Break when you get actual Changelog file, else break after MAX try. 4. If we didn't get valid Changelog file for that GFID, log GFID in stderr. 5. If Changelog file is available, Search in Changelog file for the ENTRY pattern. If found extract Parent GFID and basename. Convert Parent GFID to Path using readlink and add basename. 6. Get xattr trusted.gfid on the path we got and compare with input GFID. If both are same then we are Good, else log in stderr. (File may be changed after Create, may be Rename) 7. Collect all GFIDs from stderr and convert to Path using find . -samefile GFID FILE I created a Script using Python to find Path from GFID. Works really well if Changelog is enabled before file/dir Creation. https://github.com/aravindavk/gfid_to_path Usage: -- Download the Python Script(gfid_to_path) from https://github.com/aravindavk/gfid_to_path and place it in any bin directory which is available in PATH chmod +x /usr/local/bin/gfid_to_path To convert single GFID to Path -- echo GFID | gfid_to_path BRICK_PATH echo b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 | gfid_to_path /exports/bricks/b1 To convert list of GFIDs into Path, -- gfid_to_path BRICK_PATH GFIDS LIST FILE gfid_to_path /exports/bricks/b1 ~/collected_gfids.txt To record Converted paths in ~/good.txt and failures in ~/bad.txt - gfid_to_path BRICK_PATH GFIDS LIST FILE 1 GOOD_FILE 2 BAD_FILE gfid_to_path /exports/bricks/b1 ~/collected_gfids.txt 1 ~/good.txt 2 ~/bad.txt Source is available in Github. git clone https://github.com/aravindavk/gfid_to_path.git C S Welcome. -- regards Aravinda http://aravindavk.in ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] GFID to Path Conversion if Historical Changelogs available
Nice :) Do mention your script in the upstream doc here: https://github.com/gluster/glusterfs/blob/master/doc/debugging/gfid-to-path.md Regards, -Prashanth Pai - Original Message - From: Aravinda avish...@redhat.com To: Gluster Devel gluster-devel@gluster.org Sent: Monday, February 2, 2015 5:20:56 PM Subject: [Gluster-devel] GFID to Path Conversion if Historical Changelogs available Hi, While discussing about the possible options to convert from GFID to path, Venky suggested to search in Historical GlusterFS Changelogs and get the information about Parent GFID and basename of the file. This method works well for FOPs except Rename and Hard links. Approach: - Will consider b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 as GFID for all illustrations and file name as file1 1. If .glusterfs/b6/7b/b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 is Symlink, Readlink and Convert to relative path and Print(Easy conversion, done :)) 2. If not Symlink, Stat on file .glusterfs/b6/7b/b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 and get st_ctime(For example ctime is 1422694569) 3. Search for CHANGELOG.1422694565, CHANGELOG.1422694566.. CHANGELOG.1422694590. Break when you get actual Changelog file, else break after MAX try. 4. If we didn't get valid Changelog file for that GFID, log GFID in stderr. 5. If Changelog file is available, Search in Changelog file for the ENTRY pattern. If found extract Parent GFID and basename. Convert Parent GFID to Path using readlink and add basename. 6. Get xattr trusted.gfid on the path we got and compare with input GFID. If both are same then we are Good, else log in stderr. (File may be changed after Create, may be Rename) 7. Collect all GFIDs from stderr and convert to Path using find . -samefile GFID FILE I created a Script using Python to find Path from GFID. Works really well if Changelog is enabled before file/dir Creation. https://github.com/aravindavk/gfid_to_path Usage: -- Download the Python Script(gfid_to_path) from https://github.com/aravindavk/gfid_to_path and place it in any bin directory which is available in PATH chmod +x /usr/local/bin/gfid_to_path To convert single GFID to Path -- echo GFID | gfid_to_path BRICK_PATH echo b67b95a4-8bdc-44d5-aedd-b9b66fb0af95 | gfid_to_path /exports/bricks/b1 To convert list of GFIDs into Path, -- gfid_to_path BRICK_PATH GFIDS LIST FILE gfid_to_path /exports/bricks/b1 ~/collected_gfids.txt To record Converted paths in ~/good.txt and failures in ~/bad.txt - gfid_to_path BRICK_PATH GFIDS LIST FILE 1 GOOD_FILE 2 BAD_FILE gfid_to_path /exports/bricks/b1 ~/collected_gfids.txt 1 ~/good.txt 2 ~/bad.txt Source is available in Github. git clone https://github.com/aravindavk/gfid_to_path.git C S Welcome. -- regards Aravinda http://aravindavk.in ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Integrating liburcu source into the glusterfs source tree
liburcu is licensed under LGPLv2.1, and can be used by any software compatible with LGPL. IBM, the owners of the patent, provided their approval for this licensing [1]. We are good with regards to this. The liburcu homepage mentions that it has been tested on Linux and FreeBSD, but it should work on NetBSD as well. NetBSD has actively maintained package of liburcu [3] required by KnotDNS (another project which uses liburcu), so I'm assuming there aren't any problems there as well. We will test our changes on these three platforms to guarantee that it indeed works. We've been referring to the PhD dissertation on RCU by Paul McKenney [4] for help with implementation. Sections 5 and 6 of the dissertation discuss RCU design patterns and examples of conversion to non-RCU code to RCU. This has been a good reference for us so far. ~kaushal [1]: https://github.com/urcu/userspace-rcu/blob/master/lgpl-relicensing.txt [2]: http://urcu.so/ Under 'Architectures supported' [3]: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/userspace-rcu/ [4]: http://www.rdrop.com/~paulmck/RCU/RCUdissertation.2004.07.14e1.pdf On Tue, Feb 3, 2015 at 10:24 AM, Anand Avati av...@gluster.org wrote: Apologies for the top post. Adopting RCU is a good step. Some questions and thoughts - Does urcu work on non Linux systems, netbsd? IIRC there were Linux specific permissions on the rcu patent? Maybe only for the kernel? Would be good to confirm. Glusterd is a good place for the first prototype adoption of rcu, esp figuring out the nuances of liburcu (in my view). The perfect use case for liburcu is still brewing in the form of epoll multithreading. That patch creates the perfect conditions on the server side with many threads servicing many clients bouncing the cacheline on so many shared objects and locks - where rcu comes to the rescue. Starting with the events.c shared FD registry, client_t registry, call-pool registry, inode table, each of these are candidates which ask for rcu conversion. The unfortunate part is that cacheline bouncing fixes are all or nothing. As long as there is at least one shared lock in the hot path, the hard work gone into all the previous shared lock fixes remain latent. However the end result is well worth all the efforts. Thanks On Thu, Jan 29, 2015, 03:35 Kaushal M kshlms...@gmail.com wrote: Hi all, I had started a thread previously on the efforts we are undertaking to improve thread synchronization in GlusterD [1]. I had mentioned that we will be using RCU for synchronization and the userspace RCU library (liburcu) [2] for implementation. I am now in a almost in a position to submit changes to Gerrit for review. But, I have an obstacle of making liburcu available on the jenkins slaves. I have begun development using the 0.8.6 version of liburcu, which is the latest stable release. EPEL has liburcu packages for CentOS 6 and 7, but they are the of the older 0.7.* versions. Fedora has packages more recent packages, but they are still older, 0.8.1. [3]. Considering the above situation with binary packages, I'm considering adding liburcu into the GlusterFS tree as a part of /contrib. This will be similar in vein to the argp-standalone library. liburcu is licensed under LGPL-v2.1, so I don't think there is going to be any problem including it. But IANAL, so I would like to know of if this would if this is okay from a legal perspective. I'll add the liburcu source to our tree and push the change for review. I'm not really familiar with autotools, so I'll need some help integrating it into our build system. I'll update the list when I have pushed the change for review. In the meantime, I'd like to know if anyone has any objections to this plan. And also want to know of any alternative approaches. ~kaushal [1]: http:// http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html www.gluster.org http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html / http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html pipermail http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html / http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html gluster-devel http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html /2014-December/043382.html http://www.gluster.org/pipermail/gluster-devel/2014-December/043382.html [2]: http:// http://urcu.so/urcu.so/ http://urcu.so/ [3]: https https://apps.fedoraproject.org/packages/userspace-rcu:// https://apps.fedoraproject.org/packages/userspace-rcu apps.fedoraproject.org https://apps.fedoraproject.org/packages/userspace-rcu/packages/ https://apps.fedoraproject.org/packages/userspace-rcuuserspace-rcu https://apps.fedoraproject.org/packages/userspace-rcu ___ Gluster-devel mailing list Gluster-devel@gluster.org http:// http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 3.6.2 volume heal
On 02/03/2015 12:13 PM, Raghavendra Bhat wrote: On Monday 02 February 2015 09:07 PM, David F. Robinson wrote: I upgraded one of my bricks from 3.6.1 to 3.6.2 and I can no longer do a 'gluster volume heal homegfs info'. It hangs and never returns any information. I was trying to ensure that gfs01a had finished healing before upgrading the other machines (gfs01b, gfs02a, gfs02b) in my configuration (see below). 'gluster volume homegfs statistics' still works fine. Do I need to upgrade my other bricks to get the 'gluster volume heal homegfs info' working? Or, should I fix this issue before upgrading my other machines? Volume Name: homegfs Type: Distributed-Replicate Volume ID: 1e32672a-f1b7-4b58-ba94-58c085e59071 Status: Started Number of Bricks: 4 x 2 = 8 Transport-type: tcp Bricks: Brick1: gfsib01a.corvidtec.com:/data/brick01a/homegfs Brick2: gfsib01b.corvidtec.com:/data/brick01b/homegfs Brick3: gfsib01a.corvidtec.com:/data/brick02a/homegfs Brick4: gfsib01b.corvidtec.com:/data/brick02b/homegfs Brick5: gfsib02a.corvidtec.com:/data/brick01a/homegfs Brick6: gfsib02b.corvidtec.com:/data/brick01b/homegfs Brick7: gfsib02a.corvidtec.com:/data/brick02a/homegfs Brick8: gfsib02b.corvidtec.com:/data/brick02b/homegfs Options Reconfigured: performance.io-thread-count: 32 performance.cache-size: 128MB performance.write-behind-window-size: 128MB server.allow-insecure: on network.ping-timeout: 10 storage.owner-gid: 100 geo-replication.indexing: off geo-replication.ignore-pid-check: on changelog.changelog: on changelog.fsync-interval: 3 changelog.rollover-time: 15 server.manage-gids: on ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel CCing Pranith, the maintainer of replicate. In the meantime can you please provide the logs from the machine where you have upgraded? Anuradha already followed up with David. Seems like he got out of this situation by upgrading the other node and removing some files which went into split-brain. Next steps we are following up with David will be to check if the heal info command is run from 3.6.1 nodes or 3.6.2 nodes. Pranith Regards, Raghavendra Bhat ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
