为了尝试一下device mapper的 multipath驱动 ,于是在vmware中添加了两块scsi硬盘。想通过device mapper的multipath driver来管理这两块磁盘(当然,每个设备只有一个path)。但是在配置好multipath以后, 运行multipath –v2,输出:
Error calling out /sbin/scsi_id -g –u –s /dev/sda
查了一下,发现是scsi_id的问题。他没有返回scsi device的标识。于是跟踪scsi_id代码,发现他通过sg发送一个standard inquery,获得verndor id等。然后发送一个Supported vital product data pages(page code 0x00)inquery,以获得支持的page。该page在规范中指定是必须实现的。但是这个时候返回的数据并不是0x00 page。所以进入下面代码:
/*
* Following check is based on code once included in the 2.5.x
* kernel.
*
* Some ill behaved devices return the standard inquiry here
* rather than the evpd data, snoop the data to verify.
*/
if (buffer[3] > MODEL_LENGTH) {
/*
* If the vendor id appears in the page assume the page is
* invalid.
*/
if (!strncmp((char *)&buffer[VENDOR_LENGTH], dev_scsi->vendor, VENDOR_LENGTH)) {
info(udev, "%s: invalid page0 data\n", dev_scsi->kernel);
return 1;
}
也就是说该scsi设备仍然发送的是standard inquery命令的返回结果。因此scsi_id无法获得scsi device的标识。
装上scsi debug驱动,在OS驱动上虚拟出了scsi 块设备。执行multipath -v2.multipath驱动为该设备生成了一个多路径设备。但是路径只有一条。说明不管scsi设备不管是不是多路径的,都可以被mutipaht管理。其实这个应该是合理的。单路径的情况是多路径的一种。在vertas vm中,本地设备也会被识别成多路径设备。
scsi debug 驱动之所以能被mapper成多路径设备。就是因为它提供了一个scsi id。用scsi id命令来查询该设备,会返回一个scsi id。
看了下multipath tool的代码。它会扫描/sys/block/下的所有设备,通过调用外部程序来获得这些设备的scsi id。 这个外部程序就是我们在multpath.conf中配置的scsi id callout程序。代码的具体实现是fork一个子进程来执行该call out程序,通过管道获得call out程序的输出。并且检查call out程序是否正常返回。而我们通常用的scsi id callout 程序一般是udev中带的scsi_id。
scsi_id程序通过sg驱动向设备发送inquery命令来获取scsi id。之前所说的scsi_id不能获得本地磁盘(vmware)的scsi id就是因为本地scsi磁盘不能正常响应该命令。看了下sense data,似乎设备确实不支持page0的inquery:
sense data: 0xf0 0x50 0x00 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x24 0x00 0x00 0xc0 0x01 0x00
sense data 说明该inquery 是ILLEGAL REQUEST.出错的命令字节为0x01。也就是evpd。说明设备确实不支持Vital product data的查询。
因此,可以自己编写一个scsi_id程序,根据扫描的设备,向标准输出输出一个id,并返回0,就能实现多路径设备的聚合。
阅读(1883) | 评论(0) | 转发(0) |