From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Wed, 02 Jan 2008 16:52:03 +0000 Subject: [Cluster-devel] Re: Why the gfs2 performance regressed? In-Reply-To: <91b13c310801020844t8cd24aard6edb7aaf1110a0c@mail.gmail.com> References: <91b13c310801012353i2f57a6c4o884b3e9aeab5970a@mail.gmail.com> <1199269168.22038.29.camel@quoit> <91b13c310801020844t8cd24aard6edb7aaf1110a0c@mail.gmail.com> Message-ID: <1199292723.22038.47.camel@quoit> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On Thu, 2008-01-03 at 00:44 +0800, Cheng Renquan wrote: > On Jan 2, 2008 6:19 PM, Steven Whitehouse 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.