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.
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?
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.