[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