[Linux-cluster] Readhead Issues using cluster-1.01.00

Velu Erwan erwan at seanodes.com
Wed Nov 2 16:36:18 UTC 2005


Velu Erwan a écrit :

> Velu Erwan a écrit :
>
> 1°) Why this volume is so big ? On my system it reaches ~8192 ExaBytes !
> The first time I saw  that I thought it was an error...
>
> [root at max4 ~]# cat /proc/partitions  | grep  -e "major" -e "diapered"
> major minor  #blocks  name
> 252     0 9223372036854775807 diapered_g1v1
> [root at max4 ~]#
>
I don't know if it's normal or not but gd->capacity is set to zero then 
-1 is substract.
As gd->capacity is a unsigned long we reach the maximum size.


>
> 2°) Regarding the source code, this diaper volume never set the 
> "gd->queue->backing_dev_info.ra_pages" which is set to zero by
> gd->queue = blk_alloc_queue(GFP_KERNEL);
> Is it needed to enforce the cache/lock management or is it just a miss ?
> This could explain why the reading performances are low while 
> gfs_read() makes a generic_file_read() isn't it ?

I've made this patch which still uses a hardcoded value but where the 
diapered volume have a ra_pages set.
Using 2048 give some excellent results.
This patch make the previous one obsolete for sure. Please found it 
attached.
But I don't know how it affects gfs for its cache/lock management 
because maybe having some pages in cache could create some coherency 
troubles.

What do you think about that ?

Erwan,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cluster-1.01.00-readahead2.patch
Type: text/x-patch
Size: 331 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20051102/923f17a6/attachment.bin>


More information about the Linux-cluster mailing list