Re: [Gluster-devel] Fwd: Fwd: Bug#751888: glusterfs-server: creating symlinks generates errors
Hi Matteo, Thanks for the reproducer. I've filed a bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=454 Feel free to add yourself to the CC List to get notified of the fix. Thanks, Ravi On 06/19/2014 06:57 PM, Patrick Matthäi wrote: Hello gluster list, could you have got a look on this bug? You can access all information on http://bugs.debian.org/751888 I am on vacation from now on for nearly three weeks so I could not take care of it :-( Weitergeleitete Nachricht Betreff: Bug#751888: glusterfs-server: creating symlinks generates errors Weitersenden-Datum: Wed, 18 Jun 2014 09:39:02 + Weitersenden-Von: Matteo Checcucci Weitersenden-An: debian-bugs-d...@lists.debian.org Weitersenden-CC: Patrick Matthäi Datum: Wed, 18 Jun 2014 10:53:12 +0200 Von: Matteo Checcucci Antwort an: Matteo Checcucci , 751...@bugs.debian.org An: 751...@bugs.debian.org On 06/17/2014 04:14 PM, Patrick Matthäi wrote: Am 17.06.2014 15:29, schrieb Matteo Checcucci: ls -l, cp -a, ...). An especially troublesome consequence is that if I What is the output of: strace /bin/ls -l foobar? Anything in your server/client logs? Hello. Thanks for your quick reply. I reproduced the bug on a newly created gluster volume (connection IP over Ethernet) with gluster 3.5.0-1: ~ SERVER: host07 CLIENT: host01 , host02 , host03 , host04 root@host07:~# service glusterfs-server start root@host07:~# gluster peer status root@host07:~# gluster peer probe host01 root@host07:~# gluster peer probe host02 root@host07:~# gluster peer probe host03 root@host07:~# gluster peer probe host04 root@host07:~# pdsh -w 'host[01-04]' gluster peer probe host07 host01: peer probe: success. host02: peer probe: success. host03: peer probe: success. host04: peer probe: success. root@host07:~# gluster peer status root@host07:~# gluster volume create scratch01-04 stripe 4 host01:/data/brick1 host02:/data/brick1 host03:/data/brick1 host04:/data/brick1 root@host07:~# gluster volume start scratch01-04 root@host07:~# mkdir -p /storage/scratch01-04 root@host07:~# mount -t glusterfs host07:/scratch01-04 /storage/scratch01-04 root@host01:~# mkdir -p /storage/scratch01-04 root@host01:~# mount -t glusterfs host07:/scratch01-04 /storage/scratch01-04 root@host01:/storage/scratch01-04# ls root@host01:/storage/scratch01-04# mkdir test root@host01:/storage/scratch01-04# cd test/ root@host01:/storage/scratch01-04/test# touch foo root@host01:/storage/scratch01-04/test# ln -s foo my_link root@host01:/storage/scratch01-04/test# ls -ltr ls: cannot read symbolic link my_link: No such file or directory total 0 -rw-r--r-- 1 root root 0 Jun 18 10:07 foo lrwxrwxrwx 1 root root 3 Jun 18 10:08 my_link root@host01:~# strace /bin/ls -l foo 2> output_strace_foo root@host01:~# strace /bin/ls -l my_link 2> output_strace_my_link ~ The strace output and the logs of the server and client are attached. I hope this is useful to pinpoint the problem. Bye ___ 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] 3.5.1 beta 2 Sanity tests
On 19/06/2014, at 6:55 PM, Benjamin Turner wrote: > > I went through these a while back and removed anything that wasn't valid for > GlusterFS. This test was passing on 3.4.59 when it was released, i am > thinking it may have something to do with a sym link to the same directory bz > i found a while back? Idk, I'll get it sorted tomorrow. > > I got this sorted, I needed to add a sleep between the file create and the > link. I ran through it manually and it worked every time, took me a few goes > to think of timing issue. I didn't need this on 3.4.0.59, is there anything > that needs investigated? Any ideas? :) + 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] 3.5.1 beta 2 Sanity tests
On Tue, Jun 17, 2014 at 7:54 PM, Benjamin Turner
wrote:
> Yup,
> On Jun 17, 2014 7:45 PM, "Justin Clift" wrote:
> >
> > On 17/06/2014, at 11:33 PM, Benjamin Turner wrote:
> > > Here are the tests that failed. Note that n0 is a generated wname,
> name255 is a 255 character string, and path 1023 is a 1023 long path
>
> > >
> > > /opt/qa/tools/posix-testsuite/tests/link/02.t(Wstat: 0 Tests: 10
> Failed: 2)
> > > Failed tests: 4, 6
> > >
> > > expect 0 link ${n0} ${name255} #4
> > > expect 0 unlink ${n0} #5 <- this passed
> > > expect 0 unlink ${name255} #6
> > >
> > > /opt/qa/tools/posix-testsuite/tests/link/03.t(Wstat: 0 Tests: 16
> Failed: 2)
> > > Failed tests: 8-9
> > >
> > > expect 0 link ${n0} ${path1023} #8
> > > expect 0 unlink ${path1023} #9
> > >
> > > I gotta go for the day, I'll try to repro outside the script tomorrow.
> >
> > As a data point, people have occasionally mentioned to me in IRC
> > and via email that these "posix" tests fail for them... even when
> > run against a (non-glustered) ext4/xfs filesystem. So, it _could_
> > be just some weird spurious thing. If you figure out what though,
> > that'd be cool. :)
> >
> > + 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
> >
> I went through these a while back and removed anything that wasn't valid
> for GlusterFS. This test was passing on 3.4.59 when it was released, i am
> thinking it may have something to do with a sym link to the same directory
> bz i found a while back? Idk, I'll get it sorted tomorrow.
>
> I got this sorted, I needed to add a sleep between the file create and
the link. I ran through it manually and it worked every time, took me a
few goes to think of timing issue. I didn't need this on 3.4.0.59, is
there anything that needs investigated?
-b
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] FreeBSD experienced developers's around?
With OSX and NetBSD stability upstream i guess FreeBSD would be easier to approach. Surprised that it was posted for review upstream. On Thu, Jun 19, 2014 at 7:56 AM, Justin Clift wrote: > Hi all, > > Are there any FreeBSD developers around who are up for a bit of > a challenge? > > There's a FreeBSD port for GlusterFS here, done last year as a > Google Summer of Code project: > > https://github.com/cosql/glusterfs > (master branch) > > Wondering if someone would be interested in taking that forward, > so it works with our current git master, and then merging it > into main GlusterFS? > > 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://supercolony.gluster.org/mailman/listinfo/gluster-devel -- 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] 3.5.1-beta2 Problems with suid and sgid bits on directories
On 06/19/2014 03:39 PM, Anders Blomdell wrote: On 2014-06-19 13:48, Susant Palai wrote: Adding Susant Unfortunately things don't go so well here, with --brick-log-level=DEBUG, I get very weird results (probably because the first brick is slower to respond while it's printing debug info), I suspect I trigger some timing related bug. I attach my testscript and a log of 20 runs (with 02777 flags). The real worrisome thing here is: backing: 0 0:0 /data/disk2/gluster/test/dir1 which means that the backing store has an unreadable dir, which gets propagated to clients... I have an embryo of an theory of what happens: 1. directories are created on the first brick. 2. fuse starts to read directories from the first brick. 3. getdents64 or fstatat64 to first brick takes too long, and is redirected to second brick. 4. self-heal is initiated on second brick. On monday, I will see if I can come up with some clever firewall tricks to trigger this behaviour in a reliable way. /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] FreeBSD experienced developers's around?
Hi all, Are there any FreeBSD developers around who are up for a bit of a challenge? There's a FreeBSD port for GlusterFS here, done last year as a Google Summer of Code project: https://github.com/cosql/glusterfs (master branch) Wondering if someone would be interested in taking that forward, so it works with our current git master, and then merging it into main GlusterFS? 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://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits on directories
On 2014-06-19 13:48, Susant Palai wrote: > Adding Susant Unfortunately things don't go so well here, with --brick-log-level=DEBUG, I get very weird results (probably because the first brick is slower to respond while it's printing debug info), I suspect I trigger some timing related bug. I attach my testscript and a log of 20 runs (with 02777 flags). The real worrisome thing here is: backing: 0 0:0 /data/disk2/gluster/test/dir1 which means that the backing store has an unreadable dir, which gets propagated to clients... /Anders > > - Original Message - > From: "Anders Blomdell" > To: "Shyamsundar Ranganathan" > Cc: "Gluster Devel" > Sent: Wednesday, 18 June, 2014 9:33:04 PM > Subject: Re: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits on > directories > > On 2014-06-17 18:47, Anders Blomdell wrote: >> On 2014-06-17 17:49, Shyamsundar Ranganathan wrote: >>> You maybe looking at the problem being fixed here, [1]. >>> >>> On a lookup attribute mismatch was not being healed across >>> directories, and this patch attempts to address the same. Currently >>> the version of the patch does not heal the S_ISUID and S_ISGID bits, >>> which is work in progress (but easy enough to incorporate and test >>> based on the patch at [1]). >> Thanks, will look into it tomorrow. >> >>> On a separate note, add-brick just adds a brick to the cluster, the >>> lookup is where the heal (or creation of the directory across all sub >>> volumes in DHT xlator) is being done. >> Thanks for the clarification (I guess that a rebalance would trigger it as >> well?) > Attached slightly modified version of patch [1] seems to work correctly after > a rebalance > that is allowed to run to completion on its own, if directories are traversed > during rebalance, > some 0 dirs show spurious 01777, 0 and sometimes ends up with the > wrong permission. > > Continuing debug tomorrow... >> >>> >>> Shyam >>> >>> [1] http://review.gluster.org/#/c/6983/ >>> >>> - Original Message - From: "Anders Blomdell" To: "Gluster Devel" Sent: Tuesday, June 17, 2014 10:53:52 AM Subject: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits on directories >>> With a glusterfs-3.5.1-0.3.beta2.fc20.x86_64 with a reverted >>> 3dc56cbd16b1074d7ca1a4fe4c5bf44400eb63ff (due to local lack of IPv4 >>> addresses), I get weird behavior if I: >>> >>> 1. Create a directory with suid/sgid/sticky bit set >>> (/mnt/gluster/test) 2. Make a subdirectory of #1 >>> (/mnt/gluster/test/dir1) 3. Do an add-brick >>> >>> Before add-brick >>> >>> 755 /mnt/gluster 7775 /mnt/gluster/test 2755 /mnt/gluster/test/dir1 >>> >>> After add-brick >>> >>> 755 /mnt/gluster 1775 /mnt/gluster/test 755 /mnt/gluster/test/dir1 >>> >>> On the server it looks like this: >>> >>> 7775 /data/disk1/gluster/test 2755 /data/disk1/gluster/test/dir1 1775 >>> /data/disk2/gluster/test 755 /data/disk2/gluster/test/dir1 >>> >>> Filed as bug: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1110262 >>> >>> If somebody can point me to where the logic of add-brick is placed, I >>> can give it a shot (a find/grep on mkdir didn't immediately point me >>> to the right place). >>> >>> >> /Anders >> > /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 bug-add-brick.sh Description: application/shellscript volume create: testvol: success: please start the volume to access data volume start: testvol: success mounted: 755 0:0 /mnt/gluster mounted: 2777 0:1600 /mnt/gluster/test mounted: 2755 247:1600 /mnt/gluster/test/dir1 Before add-brick 755 /mnt/gluster 2777 /mnt/gluster/test 2755 /mnt/gluster/test/dir1 volume add-brick: success volume set: success Files /tmp/tmp.3lK6STezID and /tmp/tmp.Z2Pr46kVu1 differ ## Differ tor jun 19 15:30:01 CEST 2014 -mounted: 755 0:0 /mnt/gluster -mounted: 2777 0:1600 /mnt/gluster/test -mounted: 2755 247:1600 /mnt/gluster/test/dir1 -mounted: 2755 247:1600 /mnt/gluster/test/dir1/dir2 +755 0:0 /mnt/gluster +2777 0:1600 /mnt/gluster/test +2755 247:1600 /mnt/gluster/test/dir1 +2755 247:1600 /mnt/gluster/test/dir1/dir2 ## TIMEOUT tor jun 19 15:30:06 CEST 2014 mounted: 755 0:0 /mnt/gluster mounted: 2777 0:1600 /mnt/gluster/test mounted: 2755 247:1600 /mnt/gluster/test/dir1 mounted: 2755 247:1600 /mnt/gluster/test/dir1/dir2 backing: 2777 0:1600 /data/disk1/gluster/test backing: 2755 247:1600 /data/disk1/gluster/test/dir1 backing: 2755 247:1600 /data/disk1/gluster/test/dir1/dir2 volume create: testvol: success: please start the volume to access data volume start: testvol: success mounted: 755 0:0 /mnt/gluster mounted: 2777 0:1600 /mnt/gluster/test mounted: 2755 247:1600 /mnt/gluster/test/dir1 Before add-brick 755 /mnt/gluster 2777 /mnt/gluster/test 2755 /mnt/gluster/test/dir1 volume add-brick: success v
[Gluster-devel] Fwd: Fwd: Bug#751888: glusterfs-server: creating symlinks generates errors
Hello gluster list, could you have got a look on this bug? You can access all information on http://bugs.debian.org/751888 I am on vacation from now on for nearly three weeks so I could not take care of it :-( Weitergeleitete Nachricht Betreff: Bug#751888: glusterfs-server: creating symlinks generates errors Weitersenden-Datum: Wed, 18 Jun 2014 09:39:02 + Weitersenden-Von: Matteo Checcucci Weitersenden-An: debian-bugs-d...@lists.debian.org Weitersenden-CC: Patrick Matthäi Datum: Wed, 18 Jun 2014 10:53:12 +0200 Von: Matteo Checcucci Antwort an: Matteo Checcucci , 751...@bugs.debian.org An: 751...@bugs.debian.org On 06/17/2014 04:14 PM, Patrick Matthäi wrote: > > Am 17.06.2014 15:29, schrieb Matteo Checcucci: >> ls -l, cp -a, ...). >> An especially troublesome consequence is that if I >> > > What is the output of: > strace /bin/ls -l foobar? > > Anything in your server/client logs? > Hello. Thanks for your quick reply. I reproduced the bug on a newly created gluster volume (connection IP over Ethernet) with gluster 3.5.0-1: ~ SERVER: host07 CLIENT: host01 , host02 , host03 , host04 root@host07:~# service glusterfs-server start root@host07:~# gluster peer status root@host07:~# gluster peer probe host01 root@host07:~# gluster peer probe host02 root@host07:~# gluster peer probe host03 root@host07:~# gluster peer probe host04 root@host07:~# pdsh -w 'host[01-04]' gluster peer probe host07 host01: peer probe: success. host02: peer probe: success. host03: peer probe: success. host04: peer probe: success. root@host07:~# gluster peer status root@host07:~# gluster volume create scratch01-04 stripe 4 host01:/data/brick1 host02:/data/brick1 host03:/data/brick1 host04:/data/brick1 root@host07:~# gluster volume start scratch01-04 root@host07:~# mkdir -p /storage/scratch01-04 root@host07:~# mount -t glusterfs host07:/scratch01-04 /storage/scratch01-04 root@host01:~# mkdir -p /storage/scratch01-04 root@host01:~# mount -t glusterfs host07:/scratch01-04 /storage/scratch01-04 root@host01:/storage/scratch01-04# ls root@host01:/storage/scratch01-04# mkdir test root@host01:/storage/scratch01-04# cd test/ root@host01:/storage/scratch01-04/test# touch foo root@host01:/storage/scratch01-04/test# ln -s foo my_link root@host01:/storage/scratch01-04/test# ls -ltr ls: cannot read symbolic link my_link: No such file or directory total 0 -rw-r--r-- 1 root root 0 Jun 18 10:07 foo lrwxrwxrwx 1 root root 3 Jun 18 10:08 my_link root@host01:~# strace /bin/ls -l foo 2> output_strace_foo root@host01:~# strace /bin/ls -l my_link 2> output_strace_my_link ~ The strace output and the logs of the server and client are attached. I hope this is useful to pinpoint the problem. Bye test-gluster-3.5.0-1.tar.gz Description: application/gzip signature.asc Description: OpenPGP digital signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automating spurious failure status
On 06/19/2014 06:14 PM, Justin Clift wrote: On 19/06/2014, at 1:23 PM, Pranith Kumar Karampuri wrote: hi, I was told that Justin and I were given permission to mark a patch as verified+1 when the tests that failed are spurious failures. I think this process can be automated as well. I already have a script to parse the Console log to identify the tests that failed (I send mails using this, yet to automate the mailing part). What we need to do now is the following: 1) Find the list of tests that are modified/added as part of the commit. 2) Parse the list of tests that failed the full regression (I already have this script). Run 'prove' on these files separately say 5/10 times. If a particular test fails all the time. It is a real failure with more probability. Otherwise it is a spurious failure. If a file that is added as a new test fails even a single time, lets accept the patch after fixing the failures. Otherwise we can give +1 on it, instead of Justin/I manually doing it. Sounds good to me. :) + Justin Also send a mail to gluster-devel about the failures for each test. We'll might want to make that weekly or something? There are several failures every day. :/ Agreed. Pranith + 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] Automating spurious failure status
On 19/06/2014, at 1:23 PM, Pranith Kumar Karampuri wrote: > hi, > I was told that Justin and I were given permission to mark a patch as > verified+1 when the tests that failed are spurious failures. I think this > process can be automated as well. I already have a script to parse the > Console log to identify the tests that failed (I send mails using this, yet > to automate the mailing part). What we need to do now is the following: > 1) Find the list of tests that are modified/added as part of the commit. > 2) Parse the list of tests that failed the full regression (I already have > this script). > > Run 'prove' on these files separately say 5/10 times. If a particular test > fails all the time. It is a real failure with more probability. Otherwise it > is a spurious failure. > If a file that is added as a new test fails even a single time, lets accept > the patch after fixing the failures. > Otherwise we can give +1 on it, instead of Justin/I manually doing it. Sounds good to me. :) + Justin > Also send a mail to gluster-devel about the failures for each test. We'll might want to make that weekly or something? There are several failures every day. :/ + 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
[Gluster-devel] Automating spurious failure status
hi, I was told that Justin and I were given permission to mark a patch as verified+1 when the tests that failed are spurious failures. I think this process can be automated as well. I already have a script to parse the Console log to identify the tests that failed (I send mails using this, yet to automate the mailing part). What we need to do now is the following: 1) Find the list of tests that are modified/added as part of the commit. 2) Parse the list of tests that failed the full regression (I already have this script). Run 'prove' on these files separately say 5/10 times. If a particular test fails all the time. It is a real failure with more probability. Otherwise it is a spurious failure. If a file that is added as a new test fails even a single time, lets accept the patch after fixing the failures. Otherwise we can give +1 on it, instead of Justin/I manually doing it. Also send a mail to gluster-devel about the failures for each test. Let me know if you guys have any suggestions before I start implementing this approach. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits on directories
Adding Susant - Original Message - From: "Anders Blomdell" To: "Shyamsundar Ranganathan" Cc: "Gluster Devel" Sent: Wednesday, 18 June, 2014 9:33:04 PM Subject: Re: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits on directories On 2014-06-17 18:47, Anders Blomdell wrote: > On 2014-06-17 17:49, Shyamsundar Ranganathan wrote: >> You maybe looking at the problem being fixed here, [1]. >> >> On a lookup attribute mismatch was not being healed across >> directories, and this patch attempts to address the same. Currently >> the version of the patch does not heal the S_ISUID and S_ISGID bits, >> which is work in progress (but easy enough to incorporate and test >> based on the patch at [1]). > Thanks, will look into it tomorrow. > >> On a separate note, add-brick just adds a brick to the cluster, the >> lookup is where the heal (or creation of the directory across all sub >> volumes in DHT xlator) is being done. > Thanks for the clarification (I guess that a rebalance would trigger it as > well?) Attached slightly modified version of patch [1] seems to work correctly after a rebalance that is allowed to run to completion on its own, if directories are traversed during rebalance, some 0 dirs show spurious 01777, 0 and sometimes ends up with the wrong permission. Continuing debug tomorrow... > >> >> Shyam >> >> [1] http://review.gluster.org/#/c/6983/ >> >> - Original Message - >>> From: "Anders Blomdell" To: >>> "Gluster Devel" Sent: Tuesday, June 17, >>> 2014 10:53:52 AM Subject: [Gluster-devel] 3.5.1-beta2 Problems with >>> suid and sgid bits on directories >>> >> With a glusterfs-3.5.1-0.3.beta2.fc20.x86_64 with a reverted >> 3dc56cbd16b1074d7ca1a4fe4c5bf44400eb63ff (due to local lack of IPv4 >> addresses), I get weird behavior if I: >> >> 1. Create a directory with suid/sgid/sticky bit set >> (/mnt/gluster/test) 2. Make a subdirectory of #1 >> (/mnt/gluster/test/dir1) 3. Do an add-brick >> >> Before add-brick >> >> 755 /mnt/gluster 7775 /mnt/gluster/test 2755 /mnt/gluster/test/dir1 >> >> After add-brick >> >> 755 /mnt/gluster 1775 /mnt/gluster/test 755 /mnt/gluster/test/dir1 >> >> On the server it looks like this: >> >> 7775 /data/disk1/gluster/test 2755 /data/disk1/gluster/test/dir1 1775 >> /data/disk2/gluster/test 755 /data/disk2/gluster/test/dir1 >> >> Filed as bug: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1110262 >> >> If somebody can point me to where the logic of add-brick is placed, I >> can give it a shot (a find/grep on mkdir didn't immediately point me >> to the right place). >> >> > /Anders > /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] Regarding regression failure in rackspace-regression-2GB machine
On 19/06/2014, at 11:07 AM, Justin Clift wrote: > On 19/06/2014, at 10:52 AM, Krishnan Parthasarathi wrote: >> Pranith, >> >> The core's backtrace [1] is not 'analysable'. It doesn't show function names >> and displays "()?" for all the frames across all threads. It would be helpful >> if we had the glusterd logs corresponding to cluster.rc setup. These logs >> are missing too. > > Is there something we can do on the slaves to make it work properly? Some > sort of config change maybe? > > I'm happy to give you remote SSH to the slaves too if that's helpful. > > (just let me know if you change stuff, so I can apply the same change to > the others) As an extra thought, this is the regression test scripting code: https://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests/trees/master Feel free to suggest improvements, send merge requests, etc. :) + 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] Regarding regression failure in rackspace-regression-2GB machine
On 19/06/2014, at 10:52 AM, Krishnan Parthasarathi wrote: > Pranith, > > The core's backtrace [1] is not 'analysable'. It doesn't show function names > and displays "()?" for all the frames across all threads. It would be helpful > if we had the glusterd logs corresponding to cluster.rc setup. These logs > are missing too. Is there something we can do on the slaves to make it work properly? Some sort of config change maybe? I'm happy to give you remote SSH to the slaves too if that's helpful. (just let me know if you change stuff, so I can apply the same change to 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
[Gluster-devel] Regarding regression failure in rackspace-regression-2GB machine
Pranith, The core's backtrace [1] is not 'analysable'. It doesn't show function names and displays "()?" for all the frames across all threads. It would be helpful if we had the glusterd logs corresponding to cluster.rc setup. These logs are missing too. thanks, Krish [1] - glusterd core file can be found here - http://build.gluster.org/job/rackspace-regression-2GB/250/consoleFull ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Fwd: New Defects reported by Coverity Scan for GlusterFS
Interested to fix Coverity issues , please check the below link for how
to and guidelines:
http://www.gluster.org/community/documentation/index.php/Fixing_Issues_Reported_By_Tools_For_Static_Code_Analysis#Coverity
Thanks,
Lala
Original Message
Subject:New Defects reported by Coverity Scan for GlusterFS
Date: Thu, 19 Jun 2014 02:01:18 -0700
From: scan-ad...@coverity.com
Hi,
Please find the latest report on new defect(s) introduced to GlusterFS found
with Coverity Scan.
Defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1223229: Dereference after null check (FORWARD_NULL)
/xlators/cluster/dht/src/dht-layout.c: 728 in dht_layout_dir_mismatch()
/xlators/cluster/dht/src/dht-layout.c: 739 in dht_layout_dir_mismatch()
/xlators/cluster/dht/src/dht-layout.c: 752 in dht_layout_dir_mismatch()
/xlators/cluster/dht/src/dht-layout.c: 764 in dht_layout_dir_mismatch()
*** CID 1223229: Dereference after null check (FORWARD_NULL)
/xlators/cluster/dht/src/dht-layout.c: 728 in dht_layout_dir_mismatch()
722 pos = idx;
723 break;
724 }
725 }
726
727 if (pos == -1) {
CID 1223229: Dereference after null check (FORWARD_NULL)
Dereferencing null pointer "loc".
728 gf_msg_debug (this->name, 0,
729 "%s - no layout info for subvolume %s",
730 loc->path, subvol->name);
731 ret = 1;
732 goto out;
733 }
/xlators/cluster/dht/src/dht-layout.c: 739 in dht_layout_dir_mismatch()
733 }
734
735 err = layout->list[pos].err;
736
737 if (!xattr) {
738 if (err == 0) {
CID 1223229: Dereference after null check (FORWARD_NULL)
Dereferencing null pointer "loc".
739 gf_log (this->name, GF_LOG_INFO,
740 "%s: xattr dictionary is NULL",
741 loc->path);
742 ret = -1;
743 }
744 goto out;
/xlators/cluster/dht/src/dht-layout.c: 752 in dht_layout_dir_mismatch()
746
747 dict_ret = dict_get_ptr (xattr, conf->xattr_name,
748 &disk_layout_raw);
749
750 if (dict_ret < 0) {
751 if (err == 0 && layout->list[pos].stop) {
CID 1223229: Dereference after null check (FORWARD_NULL)
Dereferencing null pointer "loc".
752 gf_log (this->name, GF_LOG_INFO,
753 "%s: Disk layout missing, gfid = %s",
754 loc->path, gfid);
755 ret = -1;
756 }
757 goto out;
/xlators/cluster/dht/src/dht-layout.c: 764 in dht_layout_dir_mismatch()
758 }
759
760 memcpy (disk_layout, disk_layout_raw, sizeof (disk_layout));
761
762 count = ntoh32 (disk_layout[0]);
763 if (count != 1) {
CID 1223229: Dereference after null check (FORWARD_NULL)
Dereferencing null pointer "loc".
764 gf_msg (this->name, GF_LOG_ERROR, 0,
765 DHT_MSG_INVALID_DISK_LAYOUT,
766 "Invalid disk layout: invalid count %d,"
767 "path = %s, gfid = %s ", count, loc->path,
gfid);
768 ret = -1;
769 goto out;
To view the defects in Coverity Scan visit,
http://scan.coverity.com/projects/987?tab=overview
To unsubscribe from the email notification for new defects,
http://scan5.coverity.com/cgi-bin/unsubscribe.py
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] GlusterFS-3.4.4-2 RPMs on download.gluster.org
Hi, RPMs for el5-7 (RHEL, CentOS, etc.) and Fedora (19, 20, 21/rawhide), are now available in YUM repos at http://download.gluster.org/pub/gluster/glusterfs/3.4/LATEST These packages include the fix (http://review.gluster.org/#/c/8029/) for bz #https://bugzilla.redhat.com/show_bug.cgi?id=961615 . --Humble ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
