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

Re: [Linux-cluster] gfs2 partition withdrawn



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




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