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

[rae l]

On Jan 8, 2008 5:01 PM, Steven Whitehouse <swhiteho at redhat.com> wrote:
> Hi,
>
>
> On Tue, 2008-01-08 at 15:38 +0800, rae l wrote:
> > On Jan 7, 2008 7:48 PM, Steven Whitehouse <swhiteho at redhat.com> wrote:
> > > commit 60446067ba7a8e890a91db3b4a7436fe0ebd2dee
> > > Author: Marc Eshel <eshel at 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,
But when there was no 'setlease' at all in gfs2 before this commit,
(RHEL51 also no setlease), it could also work well on clusters with
multiple server.
So now it confused me that what's the defect of gfs2 without 'setlease'?
On the other hand, what's the purpose of 'setlease' method on a filesystem?

Could someone give some pointers on design of setlease?

-- 
Denis Cheng