[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] multiple gfs2_tool shrinks cause hang?



----- 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]