Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Thu, Jul 24, 2014 at 07:04:11AM +0100, Justin Clift wrote: > Surely there's some way we can make this work, such that the optimised > assembler code is only used for cpu's the support it. With non-optimised > C or something used for the others. This is The Right Way in my opinion. I think the current implementation should not have been merged, but I do not track changes close enough to had the opportunity to cast a -2 code review in time. Note that a voting NetBSD build would have catched it. This changes restores the build, we could re-enable NetBSD autobuild vote one it is merged: http://review.gluster.org/#/c/8340/ -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] spurious regression failures again! [bug-1112559.t]
Hi All, After further investigation we have the root cause for this issue. The root cause is the way in which a new node is added to the cluster. Now we have N1(127.1.1.1) and N2(127.1.1.2) as two nodes in the cluster, each having a brick N1:B1 (127.1.1.1 : 49146) and N2:B2 (127.1.1.2 : 49147) Now lets peer probe N3(127.1.1.3) from N1 1) Friend request is sent from N1 to N3. N3 added N1 in the peerinfo list i.e N1 and its uuid say [UUID1] 2) N3 get the brick infos from N1 3) N3 tries to start the bricks 1) N3 tries to start the brick B1 and find its not a local brick, using the logic MY_UUID == brickinfo->uuid, which is false in this case, as the UUID of brickinfo->hostname (N1) is [UUID1] (as suggested by the peerinfo list) and MY_UUID is [UUID3]. Hence doesn't start it. 2) N3 tries to start the brick B2. Now the problem lies here. N3 uses glusterd_resolve_brick() to resolve the UUID of B2->hostname(N2). In glusterd_resolve_brick(), it cannot find N2 in the peerinfo list. Then it checks if N2 is a local loop back address. Since N2(127.1.1.2) starts with "127" it decides that its a local loop back address. Thus glusterd_resolve_brick() fills brickinfo->uuid with [UUID3]. Now as brickinfo->uuid == MY_UUID is true, N3 initiates the brick process B2 with -s 127.1.1.2 and *-posix.glusterd-uuid=[UUID3]. This process dies off immediately, But for a short amount of time it holds on to the --brick-port, say for example 49155 All the above is observed & inferred from glusterd logs from N3 (by adding some extra debug messages) Now coming back to our test case, i.e firing snapshot create and peer probe together. If N2 has assigned 49155 as the port --brick-port for the snapshot brick, then it finds that 49155 is Already acquired by some other process(i.e faulty brick process N3:B2 (127.1.1.2 : 49155), which as the -s 127.1.1.2 and *-posix.glusterd-uuid=[UUID3]) and hence fails to start the snapshot brick process. 1) The error is spurious, as its all about chance when N2 and N3 use the same port for their brick processes. 2) This issue is possible only in a regression test scenario, As all the nodes are on the same machine, differentiated only by a different loop back address (127.1.1.*). 3) Plus The logic that "127" is a local loop back address is also not wrong as glusterd's are suppose to run on different machines in real usage cases. Please do share your thoughts on this, And what would be a possible fix. Regards, Joe - Original Message - From: "Joseph Fernandes" To: "Avra Sengupta" , "Gluster Devel" Sent: Tuesday, July 22, 2014 6:42:02 PM Subject: Re: [Gluster-devel] spurious regression failures again! [bug-1112559.t] Hi All, As with further investigation found the following, 1) Was the able to reproduce the issue, without running the complete regression, just by running bug-1112559.t only on slave30(which is been rebooted and a clean gluster setup). This rules out any involvement of previous failure from other spurious errors like mgmt_v3-locks.t. 2) Added some messages and script (netstat and ps -ef | grep gluster ) execution when the binding to a port fails (in rpc/rpc-transport/socket/src/socket.c) and found the following, Always the snapshot brick in second node (127.1.1.2) fails to acquire the port (eg : 127.1.1.2 : 49155 ) Netstat output shows: tcp0 0 127.1.1.2:49155 0.0.0.0:* LISTEN 3555/glusterfsd and the process that is holding the port 49155 is root 3555 1 0 12:38 ?00:00:00 /usr/local/sbin/glusterfsd -s 127.1.1.2 --volfile-id patchy.127.1.1.2.d-backends-2-patchy_snap_mnt -p /d/backends/3/glusterd/vols/patchy/run/127.1.1.2-d-backends-2-patchy_snap_mnt.pid -S /var/run/ff772f1ff85950660f389b0ed43ba2b7.socket --brick-name /d/backends/2/patchy_snap_mnt -l /usr/local/var/log/glusterfs/bricks/d-backends-2-patchy_snap_mnt.log --xlator-option *-posix.glusterd-uuid=3af134ec-5552-440f-ad24-1811308ca3a8 --brick-port 49155 --xlator-option patchy-server.listen-port=49155 Please note even though it says 127.1.1.2 its shows the glusterd-uuid of the 3 node that was been probed when the snapshot was created "3af134ec-5552-440f-ad24-1811308ca3a8" To clarify things there, there are already a volume brick in 127.1.1.2 root 3446 1 0 12:38 ?00:00:00 /usr/local/sbin/glusterfsd -s 127.1.1.2 --volfile-id patchy.127.1.1.2.d-backends-2-patchy_snap_mnt -p /d/backends/2/glusterd/vols/patchy/run/127.1.1.2-d-backends-2-patchy_snap_mnt.pid -S /var/run/e667c69aa7a1481c7bd567b917cd1b05.socket --brick-name /d/backends/2/patchy_snap_mnt -l /usr/local/var/log/glusterfs/bricks/d-backends-2-patchy_snap_mnt.log --xlator-option *-posix.glusterd-uuid=a7f461d0-5ea7-4b25-b6c5-388d8eb1893f --brick-port 49153 --xlator-option patchy-server.listen-p
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On 24/07/2014, at 5:05 AM, Emmanuel Dreyfus wrote: > Harshavardhana wrote: > >>> The change just disable cluster/ec when MMX is not there. If you have >>> MMX you have cluster/ec. >> Unsure - there is assembly code which depends on it but really not sure why! > > I understand this is an optimized computation: > * Multiplications in a GF(2^8) with modulus 0x11D using XOR's > > Optimization are desirable, but relying on a CPU-specific assembly seems > wrong to me, as it kills portability (what about if you want to run on > ARM?) That's a good point. There is definitely Fedora ARM and other non-x86 architectures around that we shouldn't be ruling out. Surely there's some way we can make this work, such that the optimised assembler code is only used for cpu's the support it. With non-optimised C or something used for the others. ? + 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://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Luis Pabón wrote: > Hi Emmanuel. I have a bug and a fix where cmockery2 was being linked > with all glusterfs applications. Maybe this fixes your issue: > > http://review.gluster.org/#/c/8340/ I merged there my changes for cmockery outside of default search path, Let us see if that pass autobuild. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Harshavardhana wrote: > > The change just disable cluster/ec when MMX is not there. If you have > > MMX you have cluster/ec. > Unsure - there is assembly code which depends on it but really not sure why! I understand this is an optimized computation: * Multiplications in a GF(2^8) with modulus 0x11D using XOR's Optimization are desirable, but relying on a CPU-specific assembly seems wrong to me, as it kills portability (what about if you want to run on ARM?) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [ovirt-users] Can we debug some truths/myths/facts about hosted-engine and gluster?
On 07/22/2014 07:21 AM, Itamar Heim wrote: On 07/22/2014 04:28 AM, Vijay Bellur wrote: On 07/21/2014 05:09 AM, Pranith Kumar Karampuri wrote: On 07/21/2014 02:08 PM, Jiri Moskovcak wrote: On 07/19/2014 08:58 AM, Pranith Kumar Karampuri wrote: On 07/19/2014 11:25 AM, Andrew Lau wrote: On Sat, Jul 19, 2014 at 12:03 AM, Pranith Kumar Karampuri mailto:pkara...@redhat.com>> wrote: On 07/18/2014 05:43 PM, Andrew Lau wrote: On Fri, Jul 18, 2014 at 10:06 PM, Vijay Bellur mailto:vbel...@redhat.com>> wrote: [Adding gluster-devel] On 07/18/2014 05:20 PM, Andrew Lau wrote: Hi all, As most of you have got hints from previous messages, hosted engine won't work on gluster . A quote from BZ1097639 "Using hosted engine with Gluster backed storage is currently something we really warn against. I think this bug should be closed or re-targeted at documentation, because there is nothing we can do here. Hosted engine assumes that all writes are atomic and (immediately) available for all hosts in the cluster. Gluster violates those assumptions. " I tried going through BZ1097639 but could not find much detail with respect to gluster there. A few questions around the problem: 1. Can somebody please explain in detail the scenario that causes the problem? 2. Is hosted engine performing synchronous writes to ensure that writes are durable? Also, if there is any documentation that details the hosted engine architecture that would help in enhancing our understanding of its interactions with gluster. Now my question, does this theory prevent a scenario of perhaps something like a gluster replicated volume being mounted as a glusterfs filesystem and then re-exported as the native kernel NFS share for the hosted-engine to consume? It could then be possible to chuck ctdb in there to provide a last resort failover solution. I have tried myself and suggested it to two people who are running a similar setup. Now using the native kernel NFS server for hosted-engine and they haven't reported as many issues. Curious, could anyone validate my theory on this? If we obtain more details on the use case and obtain gluster logs from the failed scenarios, we should be able to understand the problem better. That could be the first step in validating your theory or evolving further recommendations :). I'm not sure how useful this is, but Jiri Moskovcak tracked this down in an off list message. Message Quote: == We were able to track it down to this (thanks Andrew for providing the testing setup): -b686-4363-bb7e-dba99e5789b6/ha_agent service_type=hosted-engine' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/listener.py", line 165, in handle response = "success " + self._dispatch(data) File "/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/listener.py", line 261, in _dispatch .get_all_stats_for_service_type(**options) File "/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py", line 41, in get_all_stats_for_service_type d = self.get_raw_stats_for_service_type(storage_dir, service_type) File "/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py", line 74, in get_raw_stats_for_service_type f = os.open(path, direct_flag | os.O_RDONLY) OSError: [Errno 116] Stale file handle: '/rhev/data-center/mnt/localhost:_mnt_hosted-engine/c898fd2a-b686-4363-bb7e-dba99e5789b6/ha_agent/hosted-engine.metadata' Andrew/Jiri, Would it be possible to post gluster logs of both the mount and bricks on the bz? I can take a look at it once. If I gather nothing then probably I will ask for your help in re-creating the issue. Pranith Unfortunately, I don't have the logs for that setup any more.. I'll try replicate when I get a chance. If I understand the comment from the BZ, I don't think it's a gluster bug per-say, more just how gluster does its replication. hi Andrew, Thanks for that. I couldn't come to any conclusions because no logs were available. It is unlikely that self-heal is involved because there were no bricks going down/up according to the bug description. Hi, I've never had such setup, I guessed problem with gluster based on "OSError: [Errno 116] Stale file handle:" which happens when the file opened by application on client gets removed on
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Hi Emmanuel. I have a bug and a fix where cmockery2 was being linked with all glusterfs applications. Maybe this fixes your issue: http://review.gluster.org/#/c/8340/ - Luis On 07/23/2014 11:47 AM, Emmanuel Dreyfus wrote: On Wed, Jul 23, 2014 at 01:09:57PM +, Emmanuel Dreyfus wrote: I need help here: that restores the build, but I also had to fiddle with CFLAGS and LIBS, and I am not sure I did it it in the intended way. I am probbaly wrong since now glusterd breaks on startup because of cmockery2: Guard block of 0xbb28e080 size=0 allocated by (null):0 at 0xbb28e070 is corrupt ERROR: logging.c:2077 Failure! It chokes on a FREE (msgstr) that is perfectly valid. The pointer was obtained by vasprintf(), is it possible it fails to ctach allocations through vasprintf() and vonsider the bloc was not allocated? ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
> The change just disable cluster/ec when MMX is not there. If you have > MMX you have cluster/ec. > Unsure - there is assembly code which depends on it but really not sure why! -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
Harshavardhana wrote: > > http://review.gluster.org/8366 > > Dependence on MMX instruction set > > It passes autobuild and alread +1, it should be easy to merge: > > > > Much needed, but i have NetBSD 6.0 still it compiles fine in a VM? > don't you think enabling MMX would be valid here? The change just disable cluster/ec when MMX is not there. If you have MMX you have cluster/ec. Why does cluster/ec depends on MMX, btw? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] glusterfs-3.4.5 released; Release Notes
On 07/23/2014 01:08 PM, Gluster Build System wrote: SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.4.5.tar.gz This release is made off jenkins-release-85 Release Notes for 3.4.5 GA GlusterFS 3.4.5 consists entirely of bug fixes. The following changes are included in 3.4.5: * 2b78933 cluster/dht: Don't do extra unref in dht-migration checks * 33b6134 doc: Fix peer probe deficiencies * ecc2194 fuse: fix memory leak in fuse_getxattr() * b3bf2cf performance/quick-read: Check for iobuf and iobref before unref. * e311014 nfs: prevent assertion error with MOUNT over UDP ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] glusterfs-3.4.5 released
On 07/23/2014 01:08 PM, Gluster Build System wrote: SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.4.5.tar.gz This release is made off jenkins-release-85 Please allow 1-2 days for RPMs to appear on download.gluster.org. Dpkgs for Ubuntu and Debian will be available as soon as our community volunteers can make them; please be patient. Thanks. -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] glusterfs-3.4.5 released
SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.4.5.tar.gz This release is made off jenkins-release-85 -- Gluster Build System ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Wed, Jul 23, 2014 at 09:42:07AM -0700, Harshavardhana wrote: > cmockery2 is not dependent on any external libraries - i finished > FreeBSD port yesterday > https://github.com/lpabon/cmockery2/tree/master/packages/FreeBSD. > It must be showing a real bug in logging.c on NetBSD :-) Please explain it to me. I am convinced it just fails to account allocation inside vasprintf() -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
> http://review.gluster.org/8366 > Dependence on MMX instruction set > It passes autobuild and alread +1, it should be easy to merge: > Much needed, but i have NetBSD 6.0 still it compiles fine in a VM? don't you think enabling MMX would be valid here? > http://review.gluster.org/8365 > cmockery2 related problems > I will need help on that one. Even if I manage to build, glusterd > nwo crash with what seems to be a wrong unallocated-free detection > We could make it conditional if '--enable-debug' is not enabled, still discussing internally. Luis doesn't think its a good idea. cmockery2 is not dependent on any external libraries - i finished FreeBSD port yesterday https://github.com/lpabon/cmockery2/tree/master/packages/FreeBSD. It must be showing a real bug in logging.c on NetBSD :-) -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] No weekly Gluster Community Meeting this week
Hi all, A lot of people are either away or not available this week, so the weekly GlusterFS Community Meeting isn't happening this week. It'll be back on next week. (maybe new time slot, depending on outcome of the new-timeslot-poll currently being done) + 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://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Wed, Jul 23, 2014 at 04:47:04PM +0100, Justin Clift wrote: > And yeah, you're completely correct. The status of the v3.6 and master > branches at the moment seem to be "broken" for NetBSD, so work needs to > be done by people to get their bits happy again. > > We can enable the voting right now for the NetBSD autobuilds if needed. The problem is that with the changes that were rushed for release-3.6, it is now completely broken. There are two isues: http://review.gluster.org/8366 Dependence on MMX instruction set It passes autobuild and alread +1, it should be easy to merge: http://review.gluster.org/8365 cmockery2 related problems I will need help on that one. Even if I manage to build, glusterd nwo crash with what seems to be a wrong unallocated-free detection -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On Wed, Jul 23, 2014 at 01:09:57PM +, Emmanuel Dreyfus wrote: > I need help here: that restores the build, but I also had to fiddle with > CFLAGS and LIBS, and I am not sure I did it it in the intended way. I am > probbaly wrong since now glusterd breaks on startup because of cmockery2: > Guard block of 0xbb28e080 size=0 allocated by (null):0 at 0xbb28e070 is > corrupt > ERROR: logging.c:2077 Failure! It chokes on a FREE (msgstr) that is perfectly valid. The pointer was obtained by vasprintf(), is it possible it fails to ctach allocations through vasprintf() and vonsider the bloc was not allocated? -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD autobuild and cmockery2
On 23/07/2014, at 2:09 PM, Emmanuel Dreyfus wrote: > I am a bit furstrated by the status of NetBSD autobuilds: failures are > ignored for now, which makes me wonder why I spent time setting it up :-) Sorry about that Manu. :( The NetBSD autobuild has been configured to "not vote" so far, so failures in it don't really affect the PASS/FAIL outcome for a Gerrit CR. Now that v3.6 has been branched, we can enable it so failures cause the Gerrit CR to to be marked as bad. > And ignoring it lets bugs pass through. And yeah, you're completely correct. The status of the v3.6 and master branches at the moment seem to be "broken" for NetBSD, so work needs to be done by people to get their bits happy again. We can enable the voting right now for the NetBSD autobuilds if needed. (I'm not the right person to help with the technical details you need help with in the rest of the email though) Thoughts? ;) + 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://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Status of bit-rot detection
Sure :) Thanks ~Joe - Original Message - From: "Anders Blomdell" To: "Joseph Fernandes" Cc: "Gluster Devel" , "Vivek Agarwal" , "Luis Pabón" Sent: Wednesday, July 23, 2014 6:02:17 PM Subject: Re: [Gluster-devel] Status of bit-rot detection On 2014-07-23 13:42, Joseph Fernandes wrote: > Hi Anders, > > Currently we don't have an implementation/patch for bit-rot. > We are working on the design of bit-rot protection(for read-only data), as > part of Gluster Compliance. read only data is nice for archival (which is why my backups go to CDs/DVDs since 15 years back and bit-rot detection by md5 sums). > Please refer to the Gluster Compliance Proposal > http://supercolony.gluster.org/pipermail/gluster-devel/2014-June/041258.html > > If you have any design proposal/suggestion, please do share, so that we can > have a discussion on it. I'm more interested in periodically (or triggered by writes) scan and checksum all/parts of the files on gluster volumes, and compare those checksums between replicas (wont work for open files like databases/VM-images). I'll guess that I put my current tools onto each brick, and whip up some scripts to compare those. When something materializes, I'm interested in testing. > > Regards, > Joe > > - Original Message - > From: "Anders Blomdell" > To: "Gluster Devel" > Sent: Monday, July 21, 2014 10:42:00 PM > Subject: [Gluster-devel] Status of bit-rot detection > > Since switching to xfs have left me with a seemingly working system :-), > what is the current status on bit-rot detection ( > http://www.gluster.org/community/documentation/index.php/Arch/BitRot_Detection), > > any patches for me to try? /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] NetBSD autobuild and cmockery2
Hi I am a bit furstrated by the status of NetBSD autobuilds: failures are ignored for now, which makes me wonder why I spent time setting it up :-) And ignoring it lets bugs pass through. Consider cmockery2 build: it does not work if cmockery headers and libraries and installed outside of default search paths. NetBSD autobuilds choke in it because NetBSD packages are installed in /usr/pkg, but whithout any doubt we will find som eLinux distro dropping the files in /opt. Here is my attempt at fixing it by using pkg-config: http://review.gluster.org/8365 I need help here: that restores the build, but I also had to fiddle with CFLAGS and LIBS, and I am not sure I did it it in the intended way. I am probbaly wrong since now glusterd breaks on startup because of cmockery2: Guard block of 0xbb28e080 size=0 allocated by (null):0 at 0xbb28e070 is corrupt ERROR: logging.c:2077 Failure! What binaries should be linked with -lcmockery2 ? -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Status of bit-rot detection
On 2014-07-23 13:42, Joseph Fernandes wrote: > Hi Anders, > > Currently we don't have an implementation/patch for bit-rot. > We are working on the design of bit-rot protection(for read-only data), as > part of Gluster Compliance. read only data is nice for archival (which is why my backups go to CDs/DVDs since 15 years back and bit-rot detection by md5 sums). > Please refer to the Gluster Compliance Proposal > http://supercolony.gluster.org/pipermail/gluster-devel/2014-June/041258.html > > If you have any design proposal/suggestion, please do share, so that we can > have a discussion on it. I'm more interested in periodically (or triggered by writes) scan and checksum all/parts of the files on gluster volumes, and compare those checksums between replicas (wont work for open files like databases/VM-images). I'll guess that I put my current tools onto each brick, and whip up some scripts to compare those. When something materializes, I'm interested in testing. > > Regards, > Joe > > - Original Message - > From: "Anders Blomdell" > To: "Gluster Devel" > Sent: Monday, July 21, 2014 10:42:00 PM > Subject: [Gluster-devel] Status of bit-rot detection > > Since switching to xfs have left me with a seemingly working system :-), > what is the current status on bit-rot detection ( > http://www.gluster.org/community/documentation/index.php/Arch/BitRot_Detection), > > any patches for me to try? /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Status of bit-rot detection
Hi Anders, Currently we don't have an implementation/patch for bit-rot. We are working on the design of bit-rot protection(for read-only data), as part of Gluster Compliance. Please refer to the Gluster Compliance Proposal http://supercolony.gluster.org/pipermail/gluster-devel/2014-June/041258.html If you have any design proposal/suggestion, please do share, so that we can have a discussion on it. Regards, Joe - Original Message - From: "Anders Blomdell" To: "Gluster Devel" Sent: Monday, July 21, 2014 10:42:00 PM Subject: [Gluster-devel] Status of bit-rot detection Since switching to xfs have left me with a seemingly working system :-), what is the current status on bit-rot detection ( http://www.gluster.org/community/documentation/index.php/Arch/BitRot_Detection), any patches for me to try? /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cmockery2 in GlusterFS
On 07/23/2014 04:17 PM, Avra Sengupta wrote: Thanks for the fix Santosh. But i need geo-replication module and it seems the only way to get the source installed in the vm is reverting the cmockery patch for me. Either that or i have to get it online and get cmockery installed from epel. You can do one more way i.e. download the cmockery2 ZIP bundle from: https://github.com/lpabon/cmockery2/archive/master.zip to your desktop (which is connected to inet anyway) and get it scp'd to that VM (I hope that is having a IP addr) :) Am not sure if you have already tried this. Best R, Santosh On 07/23/2014 02:50 PM, Santosh Pradhan wrote: On 07/23/2014 01:04 PM, Avra Sengupta wrote: libxml could be our other dependency issue - you should build without XML --disable-xml-output ? cmockery has no dependency on libxml. geo-rep packages have dependency on libxml. So I can't install gluster with --disable-xml-output. Try --disable-xml-output --disable-georeplication. But it seems to be breaking because of Rajesh's fix of XML cli interface for snapshot. https://bugzilla.redhat.com/show_bug.cgi?id=1122186 Best R, Santosh I have a vm which isn't connected to the external network and hence cannot install cmockery on that vm through the epel repo. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] glusterfs-3.5.2beta1 RPMs available
RPMs for el5-7 (RHEL, CentOS, etc.), Fedora (19,20,21,22) are available at download.gluster.org [1]. [1] http://download.gluster.org/pub/gluster/glusterfs/qa-releases/3.5.2beta1/ Thanks, Lala On 07/21/2014 09:05 PM, Gluster Build System wrote: SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.5.2beta1.tar.gz This release is made off jenkins-release-84 -- Gluster Build System ___ Gluster-users mailing list gluster-us...@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cmockery2 in GlusterFS
Thanks for the fix Santosh. But i need geo-replication module and it seems the only way to get the source installed in the vm is reverting the cmockery patch for me. Either that or i have to get it online and get cmockery installed from epel. On 07/23/2014 02:50 PM, Santosh Pradhan wrote: On 07/23/2014 01:04 PM, Avra Sengupta wrote: libxml could be our other dependency issue - you should build without XML --disable-xml-output ? cmockery has no dependency on libxml. geo-rep packages have dependency on libxml. So I can't install gluster with --disable-xml-output. Try --disable-xml-output --disable-georeplication. But it seems to be breaking because of Rajesh's fix of XML cli interface for snapshot. https://bugzilla.redhat.com/show_bug.cgi?id=1122186 Best R, Santosh I have a vm which isn't connected to the external network and hence cannot install cmockery on that vm through the epel repo. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] IO Scheduling paper - worthy to be considered for GlusterFS ?
Hi, I came across this paper ... http://www.ece.rice.edu/~pjv/mclock.pdf while going thru a VMWare blog and this is the brief about what it claims to be : *In this paper, we presented a novel IO scheduling algorithm,* *mClock, that provides per-VM quality of service in presence of variable overall throughput. * *The QoS re-quirements for a VM are expressed as a minimum reservation, **a maximum limit, and a proportional share. * *A key aspect of mClock is its ability to enforce such controls even with fluctuating overall capacity, as shown by* *our implementation in the VMware ESX server hypervisor. * *We also presented dmClock, a distributed version of* *our algorithm that can be used in clustered storage system architectures. * *We implemented dmClock in a distributed storage environment and showed * *that it works as specified, maintaining global per-client reservations,* *limits, and proportional shares, even though the schedulers run locally * *on the storage nodes.* I thought this was worth sharing with the wider audience to see if there is any value in looking at dmclock from a GlusterFS perspective ? thanx, deepak ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cmockery2 in GlusterFS
Attached a temp fix to make the compilation go through.
-Santosh
On 07/23/2014 02:50 PM, Santosh Pradhan wrote:
On 07/23/2014 01:04 PM, Avra Sengupta wrote:
libxml could be our other dependency issue - you should build without
XML --disable-xml-output ?
cmockery has no dependency on libxml.
geo-rep packages have dependency on libxml. So I can't install
gluster with --disable-xml-output.
Try --disable-xml-output --disable-georeplication. But it seems to be
breaking because of Rajesh's fix of XML cli interface for snapshot.
https://bugzilla.redhat.com/show_bug.cgi?id=1122186
Best R,
Santosh
I have a vm which isn't connected to the external network and hence
cannot install cmockery on that vm through the epel repo.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
diff --git a/cli/src/cli-rpc-ops.c b/cli/src/cli-rpc-ops.c
index b7c6691..53e1436 100644
--- a/cli/src/cli-rpc-ops.c
+++ b/cli/src/cli-rpc-ops.c
@@ -8568,6 +8568,7 @@ cli_snapshot_status (dict_t *dict, gf_cli_rsp *rsp,
goto out;
}
+#if (HAVE_LIB_XML)
if (global_state->mode & GLUSTER_MODE_XML) {
ret = cli_xml_snapshot_status_per_snap (local->writer,
local->doc,
@@ -8578,13 +8579,16 @@ cli_snapshot_status (dict_t *dict, gf_cli_rsp *rsp,
goto out;
}
} else {
+#endif
ret = cli_get_single_snap_status (dict, key);
if (ret) {
gf_log ("cli", GF_LOG_ERROR, "Could not fetch "
"status of snap");
goto out;
}
+#if (HAVE_LIB_XML)
}
+#endif
ret = 0;
out:
diff --git a/cli/src/cli.h b/cli/src/cli.h
index 74d3599..b451d39 100644
--- a/cli/src/cli.h
+++ b/cli/src/cli.h
@@ -393,9 +393,13 @@ cli_xml_output_snap_status_begin (cli_local_t *local, int op_ret, int op_errno,
char *op_errstr);
int
cli_xml_output_snap_status_end (cli_local_t *local);
+
+#if (HAVE_LIB_XML)
int
cli_xml_snapshot_status_per_snap (xmlTextWriterPtr writer, xmlDocPtr doc,
dict_t *dict, const char *keyprefix);
+#endif
+
int
cli_xml_output_snapshot (int cmd_type, dict_t *dict, int op_ret,
int op_errno, char *op_errstr);
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cmockery2 in GlusterFS
On 07/23/2014 01:04 PM, Avra Sengupta wrote: libxml could be our other dependency issue - you should build without XML --disable-xml-output ? cmockery has no dependency on libxml. geo-rep packages have dependency on libxml. So I can't install gluster with --disable-xml-output. Try --disable-xml-output --disable-georeplication. But it seems to be breaking because of Rajesh's fix of XML cli interface for snapshot. https://bugzilla.redhat.com/show_bug.cgi?id=1122186 Best R, Santosh I have a vm which isn't connected to the external network and hence cannot install cmockery on that vm through the epel repo. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Symlinks change date while migrating
On 07/23/2014 02:44 PM, Anders Blomdell wrote: When migrating approx 1 GB of data data by doing gluster volume add-brick test new-host1:/path/to/new/brick ... gluster volume remove-brick old-host1:/path/to/old/brick ... start ... wait for removal to finish gluster volume remove-brick old-host1:/path/to/old/brick ... commit on a 3*4 -> 6*4 -> 3*4 gluster [version 3.7dev-0.9.git5b8de97] approximately 40% of the symlinks change their mtime to the time they were copied. Is this expected/known or should I file a bug? hi, Seems like a dht issue. File a bug. Assign the component to dht/'distribute' for now. If it is different component, assignee of that bug can change it accordingly. Pranith /Anders ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Symlinks change date while migrating
When migrating approx 1 GB of data data by doing gluster volume add-brick test new-host1:/path/to/new/brick ... gluster volume remove-brick old-host1:/path/to/old/brick ... start ... wait for removal to finish gluster volume remove-brick old-host1:/path/to/old/brick ... commit on a 3*4 -> 6*4 -> 3*4 gluster [version 3.7dev-0.9.git5b8de97] approximately 40% of the symlinks change their mtime to the time they were copied. Is this expected/known or should I file a bug? /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cmockery2 in GlusterFS
On 07/22/2014 11:48 AM, Harshavardhana wrote: On Mon, Jul 21, 2014 at 11:07 PM, Santosh Pradhan wrote: On 07/21/2014 10:44 PM, Luis Pabon wrote: The cmockery2 rpm is only available for the current supported Fedora versions which currently are 19 and 20. Have you tried installing cmockery2 from the source? Yes, this does not work as well because of some dependency on libxml version. Only way I get rid off this error by removing the cmockery patch. libxml could be our other dependency issue - you should build without XML --disable-xml-output ? cmockery has no dependency on libxml. geo-rep packages have dependency on libxml. So I can't install gluster with --disable-xml-output. I have a vm which isn't connected to the external network and hence cannot install cmockery on that vm through the epel repo. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
