On Tue, 2008-02-12 at 22:29 +0100, Ferenc Wagner wrote:
> Actually, I also patched my kernel tree like this. In cases when I
> forgot it, I wasn't even allowed to load the gfs module into the
> kernel. In this case the "tainted" warning was related to a slight
> vermagic mismatch, and after recompiling everything properly, it went
> away.
>
> But the issue remained: the mount command just sits there, consuming
> some CPU, and by now I've got the following console output (with my
> notes in the brackets):
> Now, mount is still stalled, and still consumes 6% of CPU.
Hi Ferenc,
This gfs hang on failed mounts is documented in bugzilla bug #425421,
and I've already got a patch for it. Since this bug was reported
internally to Red Hat, I don't know if this bug record is viewable by
the public. (I don't have control over the permission bits and how
they default, so don't shoot the messenger.) :7) The fix has not been
shipped yet due to code freeze, but I'll attach the patch that fixes
it below.
Regards,
Bob Peterson
Red Hat GFS
--
Index: ops_fstype.c
===================================================================
RCS file: /cvs/cluster/cluster/gfs-kernel/src/gfs/ops_fstype.c,v
retrieving revision 1.28.2.5
diff -w -u -p -p -u -r1.28.2.5 ops_fstype.c
--- ops_fstype.c 19 Jun 2007 21:06:10 -0000 1.28.2.5
+++ ops_fstype.c 1 Feb 2008 20:16:38 -0000
@@ -388,6 +388,7 @@ out:
return error;
fail_dput:
+ gfs_inode_put(sdp->sd_linode);
if (sb->s_root) {
dput(sb->s_root);
sb->s_root = NULL;
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
