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