This is not a normal thing to happen. Offlining is a transient state which only lasts during the time I/Os are drained. Maybe someone from iscsi land can respond but this looks like a bug.
Sumit -----Original Message----- From: storage-discuss-boun...@opensolaris.org [mailto:storage-discuss-boun...@opensolaris.org] On Behalf Of Don Sent: Monday, January 10, 2011 3:17 PM To: storage-discuss@opensolaris.org Subject: Re: [storage-discuss] Forcibly disconnect iscsi clients from comstar As a followup to my previous question- Is there a reason so much of the comstar stack likes to just wait around for things to finish that clearly won't? For example- I tried offlining the target I was having a problem with earlier. I know that there are no clients connected to it because the interface this target is bound to is down. Despite that- and despite having initiated an offline 2 hours ago- the target itself is still sitting at "offlining": r...@nas01a:~# stmfadm list-target -v iqn.1986-03.com.sun:nas01:public Target: iqn.1986-03.com.sun:nas01:public Operational Status: Offlining Provider Name : iscsit Alias : - Protocol : iSCSI Sessions : 561 What is the point of this? Why do none of the force options actually force anything? After 2 hours of waiting I would think it might make sense to realize the thing isn't going to offline of it's own accord and that it might be time to shoot it in the head. My only option at this point is to power cycle the array- it won't finish offlining and I can't bring it back online. This is not a good option but it seems like the only one I am left with. -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss _______________________________________________ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
