我正在 Debian Stretch 上尝试 gfs2，但遇到了一些困难。我是一位相当有经验的 Linux 管理员，但对共享磁盘和并行文件系统还不熟悉。
我当前的项目是在多个客户端上安装 gfs2 格式的 iscsi 导出设备作为共享文件系统。目前，我对 HA 或击剑不感兴趣，尽管这在以后可能很重要。
iscsi 部分很好，我能够登录到目标，将其格式化为 xfs 文件系统，并将其安装在多个客户端上并验证它是否显示相同的 blkid。
为了开展 gfs2 业务，我遵循 Debianstretch“gfs2”手册页上的方案，针对我的配置进行了修改，并通过各种搜索等进行了稍微修饰。
手册页在这里： https://manpages.debian.org/stretch/gfs2-utils/gfs2.5.en.html
实际的错误是，当我尝试挂载 gfs2 文件系统时，挂载命令返回
mount: mount(2) failed: /mnt: No such file or directory
...其中 /mnt 是所需的安装点，它确实存在。 （如果您尝试安装到不存在的安装点，则错误为“安装：安装点/错误不存在”）。
相关的是，在每次安装尝试时，dmesg 都会报告：
gfs2: can't find protocol lock_dlm
我简单地假设问题是 Debian 软件包不提供“/sbin/mount.gfs2”，并寻找它，但我认为这是一个错误的猜测。
我有一个五台机器的集群（Raspberry Pi，如果重要的话），命名有点特殊，pio、pi、pj、pk 和 pl。它们都有固定的静态IP地址，并且没有域。
我已经安装了 Debian gfs2、corosync 和 dlm-controld 软件包。
对于corosync步骤，我的corosync配置是（例如对于pio，旨在成为集群的主设备）：
totem {
version: 2
cluster_name: rpitest
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
nodeid: 17
interface {
ringnumber: 0
bindnetaddr: 192.168.0.17
mcastport: 5405
ttl: 1
}
}
nodelist {
node {
ring0_addr: 192.168.0.17
nodeid: 17
}
node {
ring0_addr: 192.168.0.11
nodeid: 1
}
node {
ring0_addr: 192.168.0.12
nodeid: 2
}
node {
ring0_addr: 192.168.0.13
nodeid: 3
}
node {
ring0_addr: 192.168.0.14
nodeid: 4
}
}
logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
expected_votes: 5
}
该文件存在于所有节点上，并对图腾部分中的nodeid 和bindnetaddr 字段进行了适当的特定于节点的更改。
corosync 工具在所有节点上启动时不会出现错误，并且所有节点也具有来自 corosync-quorumtool 的看起来正常的输出，因此：
root@pio:~# corosync-quorumtool
Quorum information
------------------
Date: Sun Apr 22 11:04:13 2018
Quorum provider: corosync_votequorum
Nodes: 5
Node ID: 17
Ring ID: 1/124
Quorate: Yes
Votequorum information
----------------------
Expected votes: 5
Highest expected: 5
Total votes: 5
Quorum: 3
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
1 1 192.168.0.11
2 1 192.168.0.12
3 1 192.168.0.13
4 1 192.168.0.14
17 1 192.168.0.17 (local)
dlm-controld 软件包已安装，并使用以下简单配置创建了 /etc/dlm/dlm.conf。再说一遍，我现在暂时不参加击剑比赛了。
dlm.conf 文件在所有节点上都相同。
enable_fencing=0
lockspace rpitest nodir=1
master rpitest node=17
我不清楚 DLM“lockspace”名称是否应该与 corosync 集群名称匹配。无论哪种方式，我都看到相同的行为。
dlm-controld 服务启动时没有错误，并且“dlm_tool status”的输出看起来正常：
root@pio:~# dlm_tool status
cluster nodeid 17 quorate 1 ring seq 124 124
daemon now 1367 fence_pid 0
node 1 M add 31 rem 0 fail 0 fence 0 at 0 0
node 2 M add 31 rem 0 fail 0 fence 0 at 0 0
node 3 M add 31 rem 0 fail 0 fence 0 at 0 0
node 4 M add 31 rem 0 fail 0 fence 0 at 0 0
node 17 M add 7 rem 0 fail 0 fence 0 at 0 0
gfs2 文件系统的创建者：
mkfs -t gfs2 -p lock_dlm -j 5 -t rpitest:one /path/to/device
随后，“blkid /path/to/device”报告：
/path/to/device: LABEL="rpitest:one" UUID=<stuff> TYPE="gfs2"
它在所有 iSCSI 客户端上看起来都相同。
此时，我觉得我应该能够在任何/所有客户端上安装 gfs2 文件系统，但这是我收到上面错误的地方 - mount 命令报告“没有这样的文件或目录”，并且dmesg 和 syslog 报告“gfs2：找不到协议 lock_dlm”。
还有其他几个 gfs2 指南，但其中许多似乎是特定于 RH/CentOS 的，并且适用于除 corosync 之外的其他集群管理方案，例如 cman 或pacemaker。这些不一定会破坏交易，但在几乎现货的 Debian Stretch 上进行这项工作对我来说很有价值。
在我看来，这可能是一个非常简单的 dlm 错误配置，但我似乎无法确定它。
其他线索：当我尝试通过以下方式“加入”锁空间时
dlm_tool join <name>
...我得到 dmesg 输出：
dlm cluster name 'rpitest' is being used without an application provided cluster name
这种情况的发生与我加入的锁空间是否是“rpites”无关。这表明锁空间名称和集群名称确实是同一件事，和/但 dlm 显然不知道 corosync 配置？
答案1
来自 Kconfig 文档config GFS2_FS_LOCKING_DLM：
大多数 GFS2 用户都会需要这个。它提供 GFS2 和 DLM 之间的锁定接口，这是在集群环境中使用 GFS2 所必需的。
因此，请确保您已启用它，否则使用-p lock_dlm（中的默认锁定协议gfs2_mkfs）创建的文件系统将无法使用（没有安装时覆盖）。并且lock_nolock锁定协议仅适用于单节点安装。