[Linux-cluster] dlm and IO speed problem <er, might wanna get a coffee first ; )>

[Wendy Cheng]

Wendy Cheng wrote:
> Kadlecsik Jozsef wrote:
>>
>> What is glock_inode? Does it exist or something equivalent in 
>> cluster-2.01.00?
>>   
>
> Sorry, typo. What I mean is "inoded_secs" (gfs inode daemon wake-up 
> time). This is the daemon that reclaims deleted inodes. Don't set it 
> too small though.

Have been responding to this email from top of the head, based on folks' 
descriptions. Please be aware that they are just rough thoughts and the 
responses may not fit in general cases. The above is mostly for the 
original problem description where:

1. The system is designated for build-compile - my take is that there 
are many temporary and deleted files.
2. The gfs_inode tunable was changed (to 30, instead of default, 15).

>
>>  
>> Isn't GFS_GL_HASH_SIZE too small for large amount of glocks? Being 
>> too small it results not only long linked lists but clashing at the 
>> same bucket will block otherwise parallel operations. Wouldn't it 
>> help increasing it from 8k to 65k?
>>   
>
> Worth a try.

Now I remember .... we did experiment with different hash sizes when 
this latency issue was first reported two years ago. It didn't make much 
difference. The cache flushing, on the other hand, was more significant.

-- Wendy

>
> However, the issues involved here are more than lock searching time. 
> It also has to do with cache flushing. GFS currently accumulates too 
> much dirty caches. When it starts to flush, it will pause the system 
> for too long.  Glock trimming helps - since cache flush is part of 
> glock releasing operation.
>
>
>
>