Red Hat Bugzilla – Bug 128661
Can't mount with non-default fence domain
Last modified: 2010-01-11 21:55:15 EST
Description of problem: I started fenced -n <name> with a non-default fence domain name and GFS will not mount. It gives the same errors as if you had no fenced running at all, which are: console: lock_dlm: init_fence error -1 GFS: can't mount proto = lock_dlm, table = milty:data1, hostdata = command line: [root@link-11 /]# mount -t gfs /dev/sda1 /data1 mount: permission denied Version-Release number of selected component (if applicable): gfs_mkfs DEVEL.1090955928 (built Jul 27 2004 14:20:04) Copyright (C) Red Hat, Inc. 2004 All rights reserved. How reproducible: Always. Steps to Reproduce: 1. modprobe gfs && modprobe lock_dlm && ccsd && cman_tool join 2. fenced -n BOOBOO -D 3. mount -t gfs /dev/sda1 /data1 (already a valid gfs on the device) Actual results: No mount. Expected results: Mount. Additional info: [root@link-11 /]# cat /proc/cluster/services Service Name GID LID State Code Fence Domain: "BOOBOO" 7 12 run - [2 1 3] [root@link-11 /]# cat /proc/cluster/nodes Node Votes Exp Sts Name 1 1 3 M link-12 2 1 3 M link-10 3 1 3 M link-11
This is correct behavior. GFS requires that nodes be members of the default fence domain specifically. The ability to create/join fence domains other than the default is of no use to GFS. Other users of fenced may have reason to use other domains, though, which is why it's an option. Note that there's nothing special with the name "default" per se, it's just that all gfs nodes must join the same domain (the same name.) So it can enforce this, lock_dlm requires that a gfs node joins the domain named "default".
Updating version to the right level in the defects. Sorry for the storm.