[CTDB and GFS] test: scenario and some results

[tridge at samba.org]

Ignacio,

 > yes... very strange. I tested it with OCFS and the results are quite 
 > different.
 > 
 > In local:
 > /usr/local/etc/ping_pong/ping_pong  /tmp/test 1
 >    268340 locks/sec

As Volker mentioned, OCFS doesn't have cluster coherent byte range
locking. 

It might be possible to make OCFS work with CTDB/Samba, but you would
definately need to disable "posix locking", and you'd also need to use
a different mechanism for the recovery lock. You'd also need to use a
different test than ping_pong to validate the cluster, as ping_pong
absolutely relies on correct locking. If locking isn't working right
then the results of ping_pong are meaningless.

 > The test with ping_pong -rw over OCFS2 performs with a lot of
 > 	printf("data increment = %u\n", incr)
 > lines with incr in the ranges 0..255 and don't let me read the 
 > locks/sec

right - it means that the filesystem is not coherent

 >, so I commented out the line, and yields in locks/sec:
 > 1 node:  ~ 139063
 > 2 nodes: ~   3016	3048
 > 3 nodes: ~    346	320	

unfortunately these results don't mean anything. Unless you're getting
a steady "data increment" value equal to the number of running clients
then the results aren't at all valid.

 > at the start of 1st node, prompts 1 line data increment and the 
 > locks/sec; at the start the 2nd node prompts an other line with "data 
 > increment = ..."; and at the start of the 3rd node, another line with 
 > "data increment = ..."

right - thats the correct behaviour. It means GFS is correctly lock
and data coherent, at least as far as this test is concerned. That's
great news, even if the performance isn't as good as we might hope.

Cheers, Tridge