On Wed, Apr 22, 2009 at 8:24 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 2009-04-22 at 19:09 +0800, 谢纲 wrote: >> I found that, my my kernel version is 2.6.16 (SUSE10). And the HBA >> driver are qla. The scsi async scan is not supported in this version. >> And It seems that, if the scan starts at scsi_scan_host, the naming >> order is ensured. Did the qla driver scan the lun in the thread >> qla2x00_do_dpc itself? To generate the sd name, sd_probe need to be >> invoked. I can not find the invokation in the qla driver. > > This is business as usual. The discovery order isn't guaranteed. > Without async scan it depends on machine deterministic things like the > order the bios lays out the PCI bus, but that's not going to be constant > across machines. Async scanning just makes reordering less machine > hardware dependent. Yes, I didn't find any reference of scsi_scan_host in the qla2xxx driver source code. How does the driver probe the lun, create sdev for the lun and finally invoke sd_probe to generate device file for the lun? I'm little confused about the bios order. The host controller is pci device, They may be laid out randomly by the bios. But for each host controller, the names of the luns which belong to the same host controller should be orderd. But this is not true in my case. So I think the qla driver probes the lun and contends for names in parallel. It's said that the qla2x00_rescan_fcports function is invoked in thread qla2x00_do_dpc to probe luns. But how does it works? Thanks, > > The way to cope with this is to mount devices by device id or uuid. > > James > > > -- Xie Gang -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
