[Cluster-devel] Re: Why the gfs2 performance regressed?

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Tue, 2008-01-08 at 15:38 +0800, rae l wrote:
> On Jan 7, 2008 7:48 PM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> > commit 60446067ba7a8e890a91db3b4a7436fe0ebd2dee
> > Author: Marc Eshel <eshel@almaden.ibm.com>
> > Date:   Mon Jan 15 18:33:36 2007 -0500
> >
> >     gfs2: stop giving out non-cluster-coherent leases
> >
> >
> > Now I wonder if samba is using fcntl locks rather than (incorrect, in
> > the clustered GFS2 case, since it doesn't support them) leases and that
> > is now why you are seeing the slow down. You could try (for testing
> > purposes only - don't do this with any important data) setting the
> > localflocks flag on mount and see if that makes a difference to the
> > speed.
> >
> > If it does make a difference, then the problem is just that GFS2 doesn't
> > support leases in a clustered environment. If it makes no difference,
> > then it points more towards there being a slow-down in the I/O side,
> > which seems odd since my general impression is that I/O has been getting
> > faster recently,
> that does make a difference indeed. and the git bisect work also finished,
> 
> 60446067ba7a8e890a91db3b4a7436fe0ebd2dee is first bad commit
> 
> then I tested the HEAD of gfs2-2.6-nmw:
> with 'localflocks' mount option, everything goes well and samba serves
> with high performance;
> without that mount option, something goes bad (umount.gfs2 would cause
> kernel panic) and samba serves slow down.
> 
> then I reverted that commit in the HEAD, everything goes well again,
> umount.gfs2 run and quilt normally.
> 
> So now it's time to determine: is 'localflocks' mount option
> nessessary for all clustered deployment from then on? or we can
> determine 60446067 is a bad commit really?
> 
> >
> > Steve.
> 
The patch is correct. The problem seems to be that your test was
previously incorrect since it was using local leases, whereas it
shouldn't have been using leases at all since they were not supported
across the cluster. The solution appears to be that either we need to
improve the performance of the fcntl locks, or, and I suspect better
still in the samba case, we need to look into how we might implement
cluster leases,

Steve.