Re: 'Device not ready' issue on mpt2sas since 3.1.10
Hello, On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote: Now I'm not sure this isn't taping over another bug. Which leads me to my question: What is the correct behavior? #1 Issuing a separate spin-up command (START UNIT?) prior to sending i/o by setting allow_restart=1 for sata disks on sas controllers or #2 Teaching the sas drivers they do not need spin-up commands and can simply start issuing i/o to sata disks I haven't consulted SAT but it seems like a bug in SAS driver or firmware. If it's a driver bug, we better fix it there. If a firmware bug, working around those is one of major roles of drivers, so I think setting allow_restart is fine. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'Device not ready' issue on mpt2sas since 3.1.10
Hello Tejun, Am 22.07.2012 19:31, schrieb Tejun Heo: I haven't consulted SAT but it seems like a bug in SAS driver or firmware. If it's a driver bug, we better fix it there. If a firmware bug, working around those is one of major roles of drivers, so I think setting allow_restart is fine. as it turns out my workaround (setting allow_restart=1) isn't all that useful after all. There are no more i/o errors because the drive just never goes to standby mode anymore (at least 'hdparm -y /dev/sda' does not seem to have any effect anymore). I don't really understand why - do sas drives ever get to standby mode? (they have allow_restart=1 set by default) And is this desired or expected behavior for sata disk on sas controllers? For the moment the only way for me to have my sata drives sleeping without i/o errors is to revert your original commit (85ef06d1d252f6a2e73b678591ab71caad4667bb - tested with kernels 3.1.10, 3.4.4, 3.4.5, 3.4.6 and 3.5.0) -- Matthias P.S. I hope I'm not getting on everybody's nerves here (especially yours Tejun) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about path_id of scsi hard disk
在 Sat, 21 Jul 2012 06:31:54 +0800，James Bottomley james.bottom...@hansenpartnership.com 写道: On Fri, 2012-07-20 at 16:24 +0800, gaoqiang wrote: I'm using udev to manage my hard disks. but I'm confusing about the PATH_ID gaoqiang@h150:~$/lib/udev/path_id /block/sda ID_PATH=pci-:01:00.0-scsi-0:0:0:0 the path_id is about disk or about disk slot ? Neither: it's pci function and scsi host:channel:target:lun As far as I can tell, path_id returns are completely useless for labelling disks (since host and sometimes target are scan order dependent). James I know the host:channel:target:lun but not deeply. the lun is about a disk, or a disk slot? I mean,if I take the disk on a slot and plug in a new disk,will the ID_PATH change,or not ? many thanks. -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/ -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE question about path_id of scsi hard disk
在 Sat, 21 Jul 2012 06:31:54 +0800，James Bottomley james.bottom...@hansenpartnership.com 写道: On Fri, 2012-07-20 at 16:24 +0800, gaoqiang wrote: I'm using udev to manage my hard disks. but I'm confusing about the PATH_ID gaoqiang@h150:~$/lib/udev/path_id /block/sda ID_PATH=pci-:01:00.0-scsi-0:0:0:0 the path_id is about disk or about disk slot ? Neither: it's pci function and scsi host:channel:target:lun As far as I can tell, path_id returns are completely useless for labelling disks (since host and sometimes target are scan order dependent). James I know the host:channel:target:lun but not deeply. the lun is about a disk, or a disk slot? I mean,if I take the disk on a slot and plug in a new disk,will the ID_PATH change,or not ? many thanks. [Jack Wang] It depends on driver implement. Driver base on scsi_transport_sas(like mpt2sas pm8001 isci..)the number always get bigger, but some driver bind the lun number with topology like phy number. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
