其实，我对这个东西是不甚了解的，今天恰好有个用户问到这么一个问题。那么就将以前同事遇到过的解决办法拿出来和用户解释了一番，细细考虑了一番，还是不甚了了。对于其原理还需要下一番功夫的：下面是照抄的邮件：

缺省的情况下，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即可，重新引导系统。

阅读(3939) | 评论(0) | 转发(0) |