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

Re: [Linux-cluster] Readhead Issues using cluster-1.01.00

On Thu, Nov 03, 2005 at 05:21:06PM +0100, Velu Erwan wrote:
> >- Did this problem exist a few kernel versions ago?  We should try the
> > RHEL4 kernel (or something close to it) and the version of gfs that
> > runs on that (RHEL4 cvs branch).  If that version is ok, then there's
> > probably a recent kernel change that we've missed that requires us to
> > do something new.
> I've diffed the GFS-kernel-2.6.9-42.2.src.rpm and cluster-1.01.00 and
> code is so close that it can't explain the loss of the readahead.

I'm thinking that something changed in the kernel, outside gfs, between
2.6.9-x and 2.6.13 that is causing this.  The fact that gfs is the same is
probably the problem -- gfs may need to be updated for readahead to work
properly on newer kernels.  I suspect that gfs-6.1 readahead will work
fine on 2.6.9, let's start there.

> >- Remove the diaper code and see if that changes things.  Look at these
> > patches where I removed the diaper code from gfs2; do the equivalent
> > for the version of gfs you're playing with:
> > http://sources.redhat.com/ml/cluster-cvs/2005-q3/msg00184.html
> >
> It will be my next test but it sounds like a leak in the diaper 
> implementation could be the explanation of the trouble.My patch shows it.
> Removing the diaper will make gfs using my device where the readahead is 
> already set : so the performances will be there.

OK, so something in the kernel related to block devices and readahead may
have changed recently that now requires us to set some new diaper device
values (perhaps the ones you've tried.)  We need to identify what kernel
change that was (go back through kernel changelog) and then figure out the
corresponding gfs fix.

> The gfs version I had tested (which helps me to determine what are the 
> nominal performances) was 6.0 where diaper didn't exists.

Yes, that's the right idea, and we can narrow in on the regression even
further if we find that readahead works on 6.1 + 2.6.9.  Then see if it
works on 2.6.11, etc.  Eventually we'll find the kernel where it broke and
can look through the changelog for that one kernel release.


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