OK great, that made it clear. I didn't know that locking was a bit of a can
of worms after reading a few pages on in.
I did very quickly modify the ping_pong code to change the locking mechanism
to flock and the o2cb stack locks as expected producing slightly better
performance than cman.
>From h
fcntl() locking does not pair at all with dlm locking. So both ocfs2 and gfs2
use a special scheme just for this lock. Both use the ordered messaging
provided by the corosync cluster engine. This lock is fully synchronised and
thus is not as performant as it can be. (Both cman and pacemaker use cc
OK thanks for the clarification.
Is the support of fcntl() locking within o2cb, on the wishlist of features
to be implemented at a future date? Is it even a priority to do?
Thanks, Dan
On 18 January 2011 18:00, Sunil Mushran wrote:
> ping_long tests the fcntl() user locks.
>
> ocfs2 supports
ping_long tests the fcntl() user locks.
ocfs2 supports clustered fcntl() locking with cman and pacemaker
cluster stacks. Not with o2cb.
ocfs2 supports clustered flock() with all stacks. o2cb, cman and pacemaker.
On 01/17/2011 07:25 AM, Dan Warner wrote:
I was testing ocfs2 on a 2 node cluster
I was testing ocfs2 on a 2 node cluster set up.
ocfs2-tools version is 1.6.3
ocfs2 kernel version is 2.6.36
Using cman on 2 nodes
node02 dw # ping_pong -rwm /data/test.dat 3
data increment = 2
14 locks/sec
node01 dw # ping_pong -rw /data/test.dat 3
data increment = 2
10 locks/sec
n
