Re: [Gluster-devel] Spurious failure in tests/bugs/bug-948729/bug-948729-force.t
On Wed, Dec 24, 2014 at 02:15:56PM +0530, Atin Mukherjee wrote: Can you please look into the spurious failure mentioned in $Subject @ http://build.gluster.org/job/rackspace-regression-2GB-triggered/3310/consoleFull I could see losetup is failing because of no free loop devices. Are we detaching the loop back devices in a correct way? We could also cleanup on regression begining. I also found a small problem in few functions in include.rc which I have tried to address @ http://review.gluster.org/9333. Not sure though whether this will fix this spurious failure. It seems good, but watch out netbsd regression, now we have it: http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/378/console -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] handling statfs call in USS
Hi, I have a doubt. In user serviceable snapshots as of now statfs call is not implemented. There are 2 ways how statfs can be handled. 1) Whenever snapview-client xlator gets statfs call on a path that belongs to snapshot world, it can send the statfs call to the main volume itself, with the path and the inode being set to the root of the main volume. OR 2) It can redirect the call to the snapshot world (the snapshot demon which talks to all the snapshots of that particular volume) and send back the reply that it has obtained. Please provide feedback. Regards, Raghavendra Bhat ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] handling statfs call in USS
On Wednesday 24 December 2014 02:30 PM, Raghavendra Bhat wrote: Hi, I have a doubt. In user serviceable snapshots as of now statfs call is not implemented. There are 2 ways how statfs can be handled. 1) Whenever snapview-client xlator gets statfs call on a path that belongs to snapshot world, it can send the statfs call to the main volume itself, with the path and the inode being set to the root of the main volume. In this approach, when statfs call is sent to main volume with path and inode set to the root can give incorrect value when quota and deem-statfs are enabled. path/inode should be set to the parent of '.snaps' Thanks, Vijay OR 2) It can redirect the call to the snapshot world (the snapshot demon which talks to all the snapshots of that particular volume) and send back the reply that it has obtained. Please provide feedback. Regards, Raghavendra Bhat ___ 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] Spurious failure in tests/bugs/bug-948729/bug-948729-force.t
Atin Mukherjee amukh...@redhat.com wrote: I also found a small problem in few functions in include.rc which I have tried to address @ http://review.gluster.org/9333. Not sure though whether this will fix this spurious failure. It seems it did not. Perhaps the build host needs a reboot? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Updates about DiSTAF - Multi Node test framework
Hi, I had sent a mail about new multi node test framework for glusterfs (http://www.gluster.org/pipermail/gluster-users/2014-October/019211.html).This is an update about the same. * Have changed the name to distaf - https://github.com/msvbhat/distaf About the name: DiSTAF stand for Distributed Software Test Automation Framework Also, distaff is a tool used in spinning. It makes the spinning easy by holding the unspun fibers together and keeping them untangled. The framework is supposed to do the same thing. Holding the vms/machines together and easing the process of writing and executing the tests. And since DiSTAF is pronounced same as distaff, I felt it's an apt name. * Have added couple of libraries and utilities. Things in pipeline * Using rpyc zero deploy instead of plain rpyc. The zero-deploy rpyc makes a *lot* easier to setup and run the tests. * Better logging to create a test log per test case. * Integrating with docker/dockit. There are couple of TODO's mentioned in README file. Please go through the framework once and let me know your inputs. The plan is to start using it for upstream testing soon. Best Regards, Vishwanath ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Problems with graph switch in disperse
Hi,
I'm experiencing a problem when gluster graph is changed as a result of
a replace-brick operation (probably with any other operation that
changes the graph) while the client is also doing other tasks, like
writing a file.
When operation starts, I see that the replaced brick is disconnected,
but writes continue working normally with one brick less.
At some point, another graph is created and comes online. Remaining
bricks on the old graph are disconnected and the old graph is destroyed.
I see how new write requests are sent to the new graph.
This seems correct. However there's a point where I see this:
[2014-12-24 11:29:58.541130] T [fuse-bridge.c:2305:fuse_write_resume]
0-glusterfs-fuse: 2234: WRITE (0x16dcf3c, size=131072, offset=255721472)
[2014-12-24 11:29:58.541156] T [ec-helpers.c:101:ec_trace] 2-ec:
WIND(INODELK) 0x7f8921b7a9a4(0x7f8921b78e14) [refs=5, winds=3, jobs=1]
frame=0x7f8932e92c38/0x7f8932e9e6b0, min/exp=3/3, err=0 state=1
{111:000:000} idx=0
[2014-12-24 11:29:58.541292] T [rpc-clnt.c:1384:rpc_clnt_record]
2-patchy-client-0: Auth Info: pid: 0, uid: 0, gid: 0, owner:
d025e932897f
[2014-12-24 11:29:58.541296] T [io-cache.c:133:ioc_inode_flush]
2-patchy-io-cache: locked inode(0x16d2810)
[2014-12-24 11:29:58.541354] T
[rpc-clnt.c:1241:rpc_clnt_record_build_header] 2-rpc-clnt: Request
fraglen 152, payload: 84, rpc hdr: 68
[2014-12-24 11:29:58.541408] T [io-cache.c:137:ioc_inode_flush]
2-patchy-io-cache: unlocked inode(0x16d2810)
[2014-12-24 11:29:58.541493] T [io-cache.c:133:ioc_inode_flush]
2-patchy-io-cache: locked inode(0x16d2810)
[2014-12-24 11:29:58.541536] T [io-cache.c:137:ioc_inode_flush]
2-patchy-io-cache: unlocked inode(0x16d2810)
[2014-12-24 11:29:58.541537] T [rpc-clnt.c:1577:rpc_clnt_submit]
2-rpc-clnt: submitted request (XID: 0x17 Program: GlusterFS 3.3,
ProgVers: 330, Proc: 29) to rpc-transport (patchy-client-0)
[2014-12-24 11:29:58.541646] W [fuse-bridge.c:2271:fuse_writev_cbk]
0-glusterfs-fuse: 2234: WRITE = -1 (Input/output error)
It seems that fuse still has a write request pending for graph 0. It is
resumed but it returns EIO without calling the xlator stack (operations
seen between the two log messages are from other operations and they are
sent to graph 2). I'm not sure why this happens and how I should aviod this.
I tried the same scenario with replicate and it seems to work, so there
must be something wrong in disperse, but I don't see where the problem
could be.
Any ideas ?
Thanks,
Xavi
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Problems with graph switch in disperse
Do you know the origins of EIO? fuse-bridge only fails a lookup fop with EIO
(when NULL gfid is received in a successful lookup reply). So, there might be
other xlator which is sending EIO.
- Original Message -
From: Xavier Hernandez xhernan...@datalab.es
To: Gluster Devel gluster-devel@gluster.org
Sent: Wednesday, December 24, 2014 6:25:17 PM
Subject: [Gluster-devel] Problems with graph switch in disperse
Hi,
I'm experiencing a problem when gluster graph is changed as a result of
a replace-brick operation (probably with any other operation that
changes the graph) while the client is also doing other tasks, like
writing a file.
When operation starts, I see that the replaced brick is disconnected,
but writes continue working normally with one brick less.
At some point, another graph is created and comes online. Remaining
bricks on the old graph are disconnected and the old graph is destroyed.
I see how new write requests are sent to the new graph.
This seems correct. However there's a point where I see this:
[2014-12-24 11:29:58.541130] T [fuse-bridge.c:2305:fuse_write_resume]
0-glusterfs-fuse: 2234: WRITE (0x16dcf3c, size=131072, offset=255721472)
[2014-12-24 11:29:58.541156] T [ec-helpers.c:101:ec_trace] 2-ec:
WIND(INODELK) 0x7f8921b7a9a4(0x7f8921b78e14) [refs=5, winds=3, jobs=1]
frame=0x7f8932e92c38/0x7f8932e9e6b0, min/exp=3/3, err=0 state=1
{111:000:000} idx=0
[2014-12-24 11:29:58.541292] T [rpc-clnt.c:1384:rpc_clnt_record]
2-patchy-client-0: Auth Info: pid: 0, uid: 0, gid: 0, owner:
d025e932897f
[2014-12-24 11:29:58.541296] T [io-cache.c:133:ioc_inode_flush]
2-patchy-io-cache: locked inode(0x16d2810)
[2014-12-24 11:29:58.541354] T
[rpc-clnt.c:1241:rpc_clnt_record_build_header] 2-rpc-clnt: Request
fraglen 152, payload: 84, rpc hdr: 68
[2014-12-24 11:29:58.541408] T [io-cache.c:137:ioc_inode_flush]
2-patchy-io-cache: unlocked inode(0x16d2810)
[2014-12-24 11:29:58.541493] T [io-cache.c:133:ioc_inode_flush]
2-patchy-io-cache: locked inode(0x16d2810)
[2014-12-24 11:29:58.541536] T [io-cache.c:137:ioc_inode_flush]
2-patchy-io-cache: unlocked inode(0x16d2810)
[2014-12-24 11:29:58.541537] T [rpc-clnt.c:1577:rpc_clnt_submit]
2-rpc-clnt: submitted request (XID: 0x17 Program: GlusterFS 3.3,
ProgVers: 330, Proc: 29) to rpc-transport (patchy-client-0)
[2014-12-24 11:29:58.541646] W [fuse-bridge.c:2271:fuse_writev_cbk]
0-glusterfs-fuse: 2234: WRITE = -1 (Input/output error)
It seems that fuse still has a write request pending for graph 0. It is
resumed but it returns EIO without calling the xlator stack (operations
seen between the two log messages are from other operations and they are
sent to graph 2). I'm not sure why this happens and how I should aviod this.
I tried the same scenario with replicate and it seems to work, so there
must be something wrong in disperse, but I don't see where the problem
could be.
Any ideas ?
Thanks,
Xavi
___
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
[Gluster-devel] Fwd: New Defects reported by Coverity Scan for GlusterFS
A single bug reported by covscan this time.
KP, Kaushal - can you please check this out?
Thanks,
Vijay
Forwarded Message
Subject: New Defects reported by Coverity Scan for GlusterFS
Date: Wed, 24 Dec 2014 01:55:19 -0800
From: scan-ad...@coverity.com
To: vbel...@redhat.com
Hi,
Please find the latest report on new defect(s) introduced to GlusterFS
found with Coverity Scan.
1 new defect(s) introduced to GlusterFS found with Coverity Scan.
14 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1260432: Out-of-bounds access (OVERRUN)
/xlators/mgmt/glusterd/src/glusterd.c: 1323 in glusterd_stop_uds_listener()
*** CID 1260432: Out-of-bounds access (OVERRUN)
/xlators/mgmt/glusterd/src/glusterd.c: 1323 in glusterd_stop_uds_listener()
1317 (void) rpcsvc_unregister_notify (conf-uds_rpc,
1318
glusterd_uds_rpcsvc_notify,
1319 this);
1320
1321 sock_data = dict_get (this-options, glusterd-sockfile);
1322 if (!sock_data) {
CID 1260432: Out-of-bounds access (OVERRUN)
Overrunning array sockfile of 109 bytes by passing it to a function which accesses
it at byte offset 4095 using argument 4096UL.
1323 strncpy (sockfile, DEFAULT_GLUSTERD_SOCKFILE,
PATH_MAX);
1324 } else {
1325 strncpy (sockfile, sock_data-data, PATH_MAX);
1326 }
1327 unlink (sockfile);
1328
To view the defects in Coverity Scan visit,
http://scan.coverity.com/projects/987?tab=overview
To manage Coverity Scan email notifications for vbel...@redhat.com,
click
http://scan.coverity.com/subscriptions/edit?email=vbellur%40redhat.comtoken=5b81d38a8ddcb1eaca7a29dec26cbdcc
.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
