How can I recover from a gfs2 withdrawal and fix any filesystem corruption that might exist in a Red Hat Enterprise Linux 5, 6, or 7 Resilient Storage cluster?

Solution Verified - Updated -


  • We can see a withdrawal message in the /var/log/messages. Please let us know how can we recover the filesystem?
  • My gfs2 file system is reporting invalid metadata blocks. What do I do to fix this and prevent it from occurring again?
  • A node keeps panicking with gfs2_meta_indirect_buffer in the backtrace when I have errors=panic in the mount options for a gfs2 file system.
  • A withdrawal happened on a gfs2 file system. Could this have left corruption in the metadata that needs to be fixed?
  • A withdrawal happened on a gfs2 file system. Could this have been caused by corruption?
kernel: GFS2: fsid=myCluster:myFS.1: fatal: invalid metadata block
kernel: GFS2: fsid=myCluster:myFS.1:   bh = 2119565 (magic number)
kernel: GFS2: fsid=myCluster:myFS.1:   function = gfs2_meta_indirect_buffer, file = fs/gfs2/meta_io.c, line = 401
kernel: GFS2: fsid=myCluster:myFS.1: about to withdraw this file system
kernel: GFS2: fsid=myCluster:myFS.1: telling LM to unmount
kernel: GFS2: fsid=myCluster:myFS.1: withdrawn
kernel: Pid: 3218, comm: glock_workqueue Tainted: P           ---------------    2.6.32-279.5.2.el6.x86_64 #1
kernel: Call Trace:
kernel: [<ffffffffa0761062>] ? gfs2_lm_withdraw+0x102/0x130 [gfs2]


  • Red Hat Enterprise Linux (RHEL) 5, 6, or 7 with the Resilient Storage Add On
  • A gfs2 filesystem has withdrawn

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In