[Linux-cluster] gfs2 partition withdrawn

Steven Whitehouse swhiteho at redhat.com
Mon Oct 19 10:06:17 UTC 2009


Hi,

On Sun, 2009-10-18 at 00:19 -0500, Adam Hough wrote:
> 
> 
> On Sat, Oct 3, 2009 at 6:13 AM, Nicolas Ferré
> <nicolas.ferre at univ-provence.fr> wrote:
>         Hi,
>         
>         We have a problem with our cluster, a gfs2 fs cannot be
>         accessed some times after the system reboot. I have to
>         manually umount/mount it.
>         
>         Here is the relevant part of /var/log/messages:
>         Oct  3 11:46:14 slater kernel: GFS2: fsid=crcmm:home.1: fatal:
>         invalid metadata block
>         Oct  3 11:46:14 slater kernel: GFS2: fsid=crcmm:home.1:   bh =
>         114419123 (magic number)
>         Oct  3 11:46:14 slater kernel: GFS2: fsid=crcmm:home.1:
>         function = gfs2_meta_indirect_buffer, file =
>         fs/gfs2/meta_io.c, line = 334
>         Oct  3 11:46:14 slater kernel: GFS2: fsid=crcmm:home.1: about
>         to withdraw this file system
>         Oct  3 11:46:14 slater kernel: GFS2: fsid=crcmm:home.1:
>         telling
[some messages cut]
>         Can someone explain the meaning of such messages? And how to
>         cure the problem ...
>         
>         Regards,
>         
>         -- 
>         Nicolas Ferre'
>         Laboratoire Chimie Provence
>         Universite' de Provence - France
>         Tel: +33 491282733
>         http://sites.univ-provence.fr/lcp-ct
>         
> Nicholas,
> 
> Any time you see a gfs/gfs2 filesystem withdrawn message do yourself a
> favor and do an fsck of the fileystem.
> 
> 
> These to links might explain some of what your are seeing especially
> after you run an fsck. 
> 
> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Global_File_System/s1-manage-gfswithdraw.html
> https://bugzilla.redhat.com/show_bug.cgi?id=210367
> 
I think bz #519049 is a much more likely cause. We are waiting for
verification of the patch as we cannot reproduce the issue locally, so
if someone can test this patch and confirm/deny whether it fixes the
issue then we can get on and solve this issue.

There is some circumstantial evidence to suggest that the problem does
not exist on RHEL 5.4, but that is tricky to confirm as we don't have a
lot of data to go on at the moment,

Steve.






More information about the Linux-cluster mailing list