Hi, On Thu, 2008-01-03 at 00:44 +0800, Cheng Renquan wrote: > On Jan 2, 2008 6:19 PM, Steven Whitehouse <[EMAIL PROTECTED]> wrote: > > Are you running single node? if so then use lock_nolock rather than > > lock_dlm as it will be much faster for fcntl locks. Even if you intend > > to run as a cluster eventually, a single node comparison against > > lock_nolock would be useful to try and eliminate some possibilities, > No, I'm using a two nodes environment, the /mnt/gfs2 are gfs2 mounting > points on both two nodes, and they are both samba shared folders. > And in fact, the two nodes are using a clustered LVM from the same > iSCSI device, so dlm would be the only lock manager? > > Actually What I cannot explain is merely that the only difference with > the kernel: from 2.6.18-53.el5 (stocked with RHEL51) to latest > gfs2-nmw.git, I don't know why. >
There was a performance regression with the -nmw tree relating to a set of patches which I removed from the tree this morning. That would make it slower, but not by the amount that you are seeing, and also it would affect only "normal" I/O and not fcntl locks. Is there a point in the history of the -nmw git tree which you know is ok? Perhaps it would be possible to bisect the tree to find the problem patch? Steve.