Le Sat, 23 Apr 2011 22:30:53 +0530, Ritesh Raj Sarraf <r...@debian.org> a écrit :
Hi, > On 04/23/2011 09:41 PM, Ritesh Raj Sarraf wrote: > > Can you try the > > rescan-scsi-bus.sh script from Kurt's website? We work a lot on > > that and it has good results. > > I'll file an ITP to package and ship that as it is an important > > tool in the Linux SAN space. > > It is already packaged in scsitools. Can you try that script? I will probably mix some issue here. 1) in the version in stable, when all patch are deleted, multipath -ll still list the mapping, with the version from unstable, the mapping is automatically removed. This create some confusion in my mind as I was reading that the mapping should be removed automatically when all the paths are deleted. 2) as soon as the mapping on the san is removed all the paths get faulty cc_fleet_otf_test_4_1 (3600a0b80004725120000152a4d5cdd9e) dm-0 IBM,1815 FAStT size=500G features='0' hwhandler='1 rdac' wp=rw |-+- policy='round-robin 0' prio=0 status=active | |- 0:0:1:1 sdb 8:16 active faulty running | `- 1:0:1:1 sdd 8:48 active faulty running `-+- policy='round-robin 0' prio=0 status=enabled |- 0:0:0:1 sda 8:0 active faulty running `- 1:0:0:1 sdc 8:32 active faulty running And /var/log/daemon.log gets spammed with: multipathd: sda: rdac checker reports path is ghost multipathd: checker failed path 8:0 in map cc_fleet_otf_test_4_1 multipathd: cc_fleet_otf_test_4_1: remaining active paths: 3 multipathd: dm-0: add map (uevent) multipathd: dm-0: devmap already registered multipathd: 8:16: mark as failed multipathd: cc_fleet_otf_test_4_1: remaining active paths: 2 multipathd: 8:48: mark as failed multipathd: cc_fleet_otf_test_4_1: remaining active paths: 1 multipathd: 8:32: mark as failed multipathd: cc_fleet_otf_test_4_1: remaining active paths: 0 multipathd: sdc: rdac checker reports path is ghost multipathd: sdd: rdac checker reports path is up multipathd: sda: rdac checker reports path is ghost multipathd: sdb: rdac checker reports path is up multipathd: sdc: rdac checker reports path is ghost multipathd: sdd: rdac checker reports path is up multipathd: sda: rdac checker reports path is ghost multipathd: sdb: rdac checker reports path is up multipathd: sdc: rdac checker reports path is ghost multipathd: sdd: rdac checker reports path is up multipathd: sda: rdac checker reports path is ghost multipathd: sdb: rdac checker reports path is up multipathd: sdc: rdac checker reports path is ghost multipathd: sdd: rdac checker reports path is up so it seems that the status is flipping (the up and ghost paths seems the same as when the LUN was mapped), is this expected? 3) The whole problem I have first described here could be due to the queue_if_no_path feature and the fact that some udev rules call kpartx and blkid, because when I issues dmsetup message cc_fleet_otf_test_4_1 0 fail_if_no_path the process that were stuck exit and I can then remove the previously stuck mapping. Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
