Bug 1215664

Summary:	ctdb ping_pong fails on replicated gluster volume
Product:	[Community] GlusterFS	Reporter:	sysadmin
Component:	locks	Assignee:	bugs <bugs>
Status:	CLOSED EOL	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.5.2	CC:	bugs, ndevos, pgurusid, pkarampu, rjoseph, rtalur, skoduri
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-17 15:58:30 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description sysadmin 2015-04-27 12:10:42 UTC

Description of problem:


Version-Release number of selected component (if applicable): 3.5.2-1~bpo70+1 (Debian wheezy)


How reproducible:
always

Steps to Reproduce:
1. create new shared gluster volume
2. mount the volume on the nodes 
3. run ctdb's "ping_pong -rw <filename> <node_count>" on the cluster

Actual results:
on all nodes, the data_increment value always stays at 1, while the locks/sec decrease as expected when running ping_pong -rw on the other nodes as well.

Expected results:
data_increment should be equal to the number of nodes currently running ping_pong. 

Additional info:
# gluster volume info shared
 
Volume Name: shared
Type: Replicate
Volume ID: 24925301-8009-44f6-ab55-5e3c5da47cea
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: node1:/mnt/gluster
Brick2: node2:/mnt/gluster
Brick3: node3:/mnt/gluster
Options Reconfigured:
performance.stat-prefetch: off
storage.batch-fsync-delay-usec: 0
cluster.post-op-delay-secs: 0
performance.write-behind: off
cluster.eager-lock: off
server.statedump-path: /tmp
features.lock-heal: on

playing around with the volume settings didn't get us anywhere.

Comment 1 sysadmin 2015-04-28 15:22:29 UTC

After upgrading the Kernel from 3.2.68-1+deb7u1 to 3.16.7-ckt9-2~bpo70+1 and rebooting the cluster, the ctdb ping_pong rw test works as it's supposed to.

Can anyone explain to me why this test fails with the older kernel?

Comment 2 Niels de Vos 2016-06-17 15:58:30 UTC

This bug is getting closed because the 3.5 is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release.