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

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



David Teigland a écrit :

[...]

I don't know, but here are a couple things you might look into:

- 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 <http://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/RHGFS/SRPMS/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.

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

I suspect that read-ahead should indeed be happening and that something
has broken it recently.  I think we should first figure out how it worked
in the past.
I don't manage how the diaperer disk could have a readahead value if gfs doesn't specify one even more when the diapered volume can't be tuned using blktool or hdparm.


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