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.
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
