----- Original Message ----- | Hi all, | I recently had a hang on our cluster that I unwittingly caused and | wondered if anyone else has seen anything similar. We were noticing a | definitely slow-down in one filesystem and doing some investigation, I | noticed that one of the nodes had a large number of locks gfs2_glock | in | /proc/slabinfo was very large. I decided to try doing a gfs2_tool | shrink on the filesystem that was going to slow. I noticed some | reduction in the number of locks, but not a lot, so I did it again. | Everything dropped into D wait on that filesystem, as did several of | the | kernel threads. Has anyone else seen this behavior? Is this a known | bug? | | -- scooter Hi Scooter, I don't know of any problems with gfs2_tool shrink. Since GFS2 is self-tuning, people don't use gfs2_tool shrink. As a matter of fact, I'm not even sure if it's tested. Feel free to open a bugzilla record (or a Red Hat support case if applicable) for us to investigate the gfs2_tool shrink issue. If the original problem occurs again, please consider compiling and running the glock analyzer tool on my people page: http://people.redhat.com/rpeterso/Experimental/RHEL5.x/gfs2/gfs2_hangalyzer.c Instructions are contained in comments at the top. Then post to a bugzilla record: (1) the program's output, (2) the files it downloaded into /tmp/ and (3) the output from sysrq-t showing the call traces of all processes from syslog. Regards, Bob Peterson Red Hat File Systems -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
