[Linux-cluster] Readhead Issues using cluster-1.01.00

[Velu Erwan]

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.