☰

光纤通道机柜中的热插拔驱动器报告错误大小

tag-icon • tag-icon ubuntu fibre-channel udev
光纤通道机柜中的热插拔驱动器报告错误大小

首先，我们甚至不确定这是否是一个 udev 问题，但我们需要一个地方来开始询问...我们有一个日立光纤通道 SAN，为几台运行 ubuntu server 12.04 amd64 的机器提供卷服务。

为了映射目的，我们使用 udev 生成的 /dev/disk/by-id 标识符

...
/dev/disk/by-id/scsi-1HITACHI_750505270125
/dev/disk/by-id/scsi-1HITACHI_750505270125-part1
/dev/disk/by-id/scsi-1HITACHI_750505270126
/dev/disk/by-id/scsi-1HITACHI_750505270126-part1
...

最后 4 位数字（0125、0126、0127...）标识在 Hitachi 上创建的 LUN，因此我们知道正在访问哪个物理卷。

我们发现了一个奇怪的问题，我们在 LUN 125 上有一个 1.1T 卷，我们在机舱侧将其分解成更小的块。将其中一个新驱动器重新分配给服务器后，似乎卷大小被缓存了（请参阅1150.5 GB尺寸）...

root@server1:~# fdisk -l /dev/disk/by-id/scsi-1HITACHI_750505270125

Disk /dev/disk/by-id/scsi-1HITACHI_750505270125: 1150.5 GB, 1150514364416 bytes
255 heads, 63 sectors/track, 139875 cylinders, total 2247098368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

                                      Device Boot      Start         End      Blocks   Id  System
/dev/disk/by-id/scsi-1HITACHI_750505270125-part1              63  1048575999   524287968+  83  Linux

奇怪的是，我们将相同的卷连接到另一台机器。它们不活跃，但仍然可见。我们看到了同样的行为，但重新启动后驱动器看起来正常（参见536.9 GB尺寸）：

root@server2:~# fdisk -l /dev/disk/by-id/scsi-1HITACHI_750505270125

Disk /dev/disk/by-id/scsi-1HITACHI_750505270125: 536.9 GB, 536870912000 bytes
255 heads, 63 sectors/track, 65270 cylinders, total 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

                                      Device Boot      Start         End      Blocks   Id  System
/dev/disk/by-id/scsi-1HITACHI_750505270125-part1              63  1048575999   524287968+  83  Linux

有趣的是，我们在第二台服务器（server2）上对驱动器进行了分区，该服务器可以看到正确的大小，而在第一台服务器（server1）上我们可以看到该分区，即使实际驱动器大小仍然是旧的。我们甚至将其格式化并安装在 server2 上，写入一个 txt 文件，卸载它，在 server1 上重新安装它，果然，我们可以看到并访问该 txt 文件。

看起来好像有人在某处缓存卷大小？

为了以防万一，在分离并重新连接驱动器后，我们重新扫描 LUN 并运行udevadm trigger以刷新 udev 树...

我们真的不太愿意使用具有这种差异的驱动器，如果我们需要重新启动才能让系统显示实际大小，我们将失去热插拔的所有优势...关于这种情况是如何发生的，有什么想法吗？使用这些卷是否安全而无需重新启动？

附带一个问题，当我们从光纤舱中分离驱动器时，我们运行udevadm trigger，看起来 udev 只是添加了新的驱动器（设备），但它并没有删除已经消失的设备……应该是这样吗？

答案1

由于涉及多个层，因此有多个命令可以发挥作用。

用于更新/重新扫描

足球俱乐部
只需简单扫描公交车运行情况：

echo "1" > /sys/class/fc_host/hostXYZ/issue_lip
echo "- - -" > /sys/class/scsi_host/hostXYZ/scan

如果您提前知道总线/目标/lun，您可以说：

echo "b t l" > /sys/class/scsi_host/hostXYZ/scan

您b t l用总线目标和 lun 号替换。

A小型计算机系统接口更新磁盘缩小/增长大小的特定命令是

echo 1 > /sys/block/sdX/device/rescan

您需要知道相应的驱动器规范名称，例如 sda。

移除/删除磁盘

（显然你需要替换 sda 和 0:0:0）

卸载该磁盘上的所有内容

从中删除小型计算机系统接口层

echo 1 > /sys/class/block/sda/device/delete

从中删除足球俱乐部层

echo 1 > /sys/class/fc_transport/target0\:0\:0/device/0\:0\:0\:0/delete

现在您可以安全地将其从 SAN 中删除。

相关内容