[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

-- 
Denis Cheng


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]