其实,我对这个东西是不甚了解的,今天恰好有个用户问到这么一个问题。那么就将以前同事遇到过的解决办法拿出来和用户解释了一番,细细考虑了一番,还是不甚了了。对于其原理还需要下一番功夫的:下面是照抄的邮件:
缺省的情况下,Linux 内核不会支持多LUN(Logic Unit Number),换一个说法是不
支持lun!=0的设备。
其原因是并不是所有的设备都能很好的支持多LUN,首先LUN这术语起源于RAID等设
备的需要,因为在RAID里,16bit的SCSI设备,仅仅能使用15个SCSI设备,这不利
于RAID的扩展,于是在每一个ID后面,采取了子ID设备编址策略的方式,也就是
LUN,每一个ID可以再划为8个 LUN,于是一个SCSI卡,就能扩展为8*15=120个设
备,基本能满足需求。
不过随着技术的发展,采取多SCSI卡,而不是多LUN的方式占了上风。而且多LUN的
情况不在SCSI协议标准里,因此导致早期非常多的设备在支持多 LUN上非常糟糕,
包括像IBM,HP,HITACHI,NEC等国际知名品牌。
出现的故障一般是两种:一来是导致SCSI卡被锁定,从而系统处于停滞状态,无法
继续后面的操作;第二种是会导致SCSI总线重置(reset),这就会使得inquiry命令
重复使用。想知道到底有多少设备不能正常支持多LUN,你可以看看内核源代码的
drivers/scsi/scsi_devinfo.c文件就知道了。
另外一种情况,虽然还不至于导致系统停止,但是也会很郁闷,那就是你扫描出来
的一堆设备实际上都是一个同一个设备--LUN0。大家如果还有印象的话,在配置绝
大部分存储的时候,都会问你主机操作系统的型号,其目的就是防止这个的,一个
实例就是在如果操作系统选择windows,在windows系统里,就会发现大量的重复设备。
解决办法,据说是有两种,但我仅相信一种,那就是
在此我们先验证下scsi_mod的具体属性:
lee@lee-laptop:/media/sda7/etc$ modinfo scsi_mod
filename: /lib/modules/2.6.24-17-generic/kernel/drivers/scsi/scsi_mod.ko
license: GPL
description: SCSI core
srcversion: EF1811D2FA85DB0034DF422
depends:
vermagic: 2.6.24-17-generic SMP mod_unload 586
parm: dev_flags:Given scsi_dev_flags=vendor:model:flags[,v:m:f] add black/white list entries for vendor and model with an integer value of flags to the scsi device info list (string)
parm: default_dev_flags:scsi default device flag integer value (int)
parm: max_luns:last scsi LUN (should be between 1 and 2^32-1) (uint)
parm: scan:sync, async or none (string)
parm: max_report_luns:REPORT LUNS maximum number of LUNS received (should be between 1 and 16384) (uint)
parm: inq_timeout:Timeout (in seconds) waiting for devices to answer INQUIRY. Default is 5. Some non-compliant devices need more. (uint)
parm: scsi_logging_level:a bit mask of logging levels (int)
大家可以看到红色的那行,那么在/etc/modprobe.conf中添加options scsi_mod max_luns=255,然后重新生成init.img即可,重新引导系统。
阅读(4707) | 评论(0) | 转发(0) |