向服务器添加新磁盘后 zpool 不可用(挂载点已更改)

向服务器添加新磁盘后 zpool 不可用(挂载点已更改)

我有一个运行 Proxmox 的家庭服务器,有两个 zpools。我想用一个新的池替换一个带有较小硬盘的现有池。但是当我插入两个新的 SATA 硬盘中的一个时,我的 zpools 无法工作。日志显示缺少一个重要磁盘。当我发送新磁盘时,一切都正常。

我发现我的新的磁盘已安装到。但是,当未插入新磁盘时,sda现有 zpool 中的一个旧磁盘也已安装到。我该怎么做才能避免这种冲突?我需要告诉 linux 哪个是 zpool 中为旧磁盘保留的,哪个应该用于新磁盘。sdasdasdg

我很困惑这种行为竟然会发生。因此,Linux 似乎不会将挂载点绑定到驱动器,就像 Windows 中的驱动器号一样。我认为使用挂载点是一个错误,我应该在 zpool 中使用一些唯一标识符(UUID?)。但我该怎么做呢?我有现有的 zfs 池,我在其中使用了挂载点。

答案1

有关问题的一些背景知识

经过一番研究和尝试,我发现 zfs 使用了挂载点。所以我的理论是正确的:挂载点不像 Windows 中的驱动器号那样是静态的。相反,Linux 按照启动期间检测的顺序分配它们。添加或删除磁盘可能会混淆挂载点。

简单示例:

sda -> Drive #1
sdb -> Drive #2
sdc -> Drive #3

现在我们添加一个新的驱动器 #4。它可以像这样插入:

sda -> Drive #1
sdb -> Drive #4
sdc -> Drive #2
sde -> Drive #3

如果我们依赖挂载点,那么现在就麻烦了:我们的系统期望驱动器 #2 在 中sdb,但得到的却是一个完全不同的驱动器(驱动器 #4)。根据 arch wiki,这种情况甚至可能在常规启动过程中发生,没有对硬盘的任何更改。

我们可以做什么?

嗯,使用这些挂载点似乎不是一个好主意。我们应该使用持久块设备命名相反,可以使用 udev 获得。它应该在任何现代 Linux 发行版上都可用。持久块名称不使用中性名称(如sda或 )sdb。相反,它会创建某种名称,这些名称会永久绑定到驱动器。它们与 Windows 中的驱动器号相当(是的,请记住驱动器号绑定到分区,其中块名称标识驱动器,但它们都是持久的!)。

by-id并且by-uuid似乎最适用于解决此问题,但还有其他问题。您可以在 Arch 的链接 wiki 页面中阅读更详细的解释。这是一篇通用文章,也可以应用于其他发行版。对于这个问题,重要的是要知道,这uuids是一种生成的唯一 ID。我们可以使用ids一种更易读的替代方案,因为它们使用的是硬盘特定信息,如制造商、型号和序列号。

虚拟文件系统

作为描述在这里,需要导出所有池,然后重新导入它们,但要使用开关-d。它告诉 zpool 在哪里查找设备:

zpool export <poolname>
zpool import -d /dev/disk/by-id <poolname>

使用zpool status此方法可以验证:在导出/导入之前,您应该看到/dev/sda设备的安装点。这些步骤完成后,应该会更改为磁盘 ID。

常规卷(可选)

对我来说这还不够:我还有一个额外的硬盘缓冲用于 ISO 映像之类的东西。没有重要数据,只是为了减轻我的 SSD 负担。所以这是一个经典的 ext3 卷。这阻止了我的服务器启动,因为这里发生了完全相同的问题:由于新磁盘,挂载点发生了变化,导致挂载失败。

我通过简单地移除这个驱动器解决了这个问题。无论如何,这是我的想法,因为新的硬盘足够大,我可以通过减少磁盘来节省一些能源。为此,我们必须使用/etc/pve/storage.cfg文件从 proxmox 中删除存储。在我的情况下,相关部分如下所示:

dir: buffer
path /buffer
content iso

删除它之后,我们必须查看一下/etc/fstab。此文件挂载了我们的/buffer卷,根本原因就发生在这里:

/dev/sdf /buffer ext3 rw 0 0

如您所见,挂载点/dev/sdf就在这里。如果你不想像我一样拒绝磁盘,只需在这里使用一个唯一的挂载点!例如 /dev/disk/by-id。这是持久块设备名称的示例。它们是基于设备相关数据生成的。by-id例如,使用硬件序列号。因此,我们甚至可以为两个相同的磁盘设置设备。请阅读第一段以了解更多背景信息。

就我而言,只需删除此行即可阻止 Linux 挂载我的硬盘。如果您有更多卷,则需要对每个卷重复这些步骤,以确保重启后不会遇到任何问题。

相关内容