Erez Zilber <erezz@xxxxxxxxxxxx> wrote: > Starting open-iscsi: > > [root@DBD6 ~]# /etc/init.d/iscsi start > Starting iSCSI initiator service: [ OK ] > Setting up iSCSI targets: Login session [192.168.60.224:3260 > iqn.2000-03.com.falconstor-ipstor.sr4g.Everyone-iSCSI-10005] > Login session [192.168.60.223:3260 > iqn.2000-03.com.falconstor-ipstor.fiona.D2-3] > Login session [192.168.60.223:3260 > iqn.2000-03.com.falconstor-ipstor.fiona.Everyone-iSCSI-4] > [ OK ] > Starting multipath: > > [root@DBD6 ~]# /etc/init.d/multipathd start > Starting multipathd daemon: [ OK ] > > Now, we have some iSCSI sessions: > > [root@DBD6 ~]# iscsiadm -m session > iser: [1] 192.168.60.224:3260,0 > iqn.2000-03.com.falconstor-ipstor.sr4g.Everyone-iSCSI-10005 > iser: [2] 192.168.60.223:3260,0 iqn.2000-03.com.falconstor-ipstor.fiona.D2-3 > iser: [3] 192.168.60.223:3260,0 > iqn.2000-03.com.falconstor-ipstor.fiona.Everyone-iSCSI-4 > > Stopping multipath: > > [root@DBD6 ~]# /etc/init.d/multipathd stop > Stopping multipathd daemon: [ OK ] > Stopping multipathd will result in no listener for events to cleanup the multipath tables if devices are removed. If you leave multipathd running and just start and stop iscsi do things work correctly? > Stopping open-iscsi: > > [root@DBD6 ~]# /etc/init.d/iscsi stop > Stopping iSCSI initiator service: Logout session [1][192.168.60.224:3260 > iqn.2000-03.com.falconstor-ipstor.sr4g.Everyone-iSCSI-10005] > Logout session [2][192.168.60.223:3260 > iqn.2000-03.com.falconstor-ipstor.fiona.D2-3] > Logout session [3][192.168.60.223:3260 > iqn.2000-03.com.falconstor-ipstor.fiona.Everyone-iSCSI-4] > [ OK ] > > Now, the multipath module is still running (I'm not sure if that's a > problem): > No, the modules being loaded in the kernel is ok even if you have no multipath tables loaded. > [root@DBD6 ~]# lsmod|grep mul > dm_multipath 22865 2 dm_round_robin > dm_mod 74153 10 dm_mirror,dm_multipath > > Looking at the multipath devices returns strange results (since the > iSCSI devices are already gone): > The strange status below is the result of the devices being in the process of being removed, but the multipath table still contain entries for these devices. > [root@DBD6 ~]# multipath -l > mpath1 (3600d02300063ccc6000000018031a702) > [size=21 GB][features="1 queue_if_no_path"][hwhandler="0"] > \_ round-robin 0 [active] > \_ #:#:#:# - 8:32 [active] > > mpath0 (3600d02300063ccc6000000018031a701) > [size=20 GB][features="1 queue_if_no_path"][hwhandler="0"] > \_ round-robin 0 [enabled] > \_ #:#:#:# - 8:48 [active] > \_ round-robin 0 [enabled] > \_ #:#:#:# - 8:16 [active] > > .. snip .. > > Now, some questions: > > 1. Is it a known bug > 2. If yes, is there any workaround? If you leave multipathd running it should effect your error case in a postive way. > 3. Is there a newer version of dm that works ok on RHAS4 up5? Which > version? > 4. In RHEL5, this test seems to work ok, but I see that after running > /etc/init.d/multipath stop, the dm modules are still running. Why? > 5. IN RHEL5, if I do the following: > 1. start open-iscsi > 2. start multipath > 3. stop multipath > 4. stop open-iscsi > 5. start open-iscsi - now running 'multipath -l' shows the > multipath devices althoguh the multipath service is stopped. > Why? Previously I had run some experiments with FC removal and multipath devices. The version are not a direct match to your test case, but show that event processing does work. Here is a url to the old email. http://permalink.gmane.org/gmane.linux.scsi/36165 -andmike -- Michael Anderson andmike@xxxxxxxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
