Hi Eugene, that for trying that. If the problem is the same even when you revert to the snv_97 version of the iscsitgtd, then maybe the problem is in how the iScsi target interacts with some other Solaris sub-systems.
That is what I'm beginning to suspect. Maybe something outside the iscsi target code has changed that is having an adverse effect or strange interaction. Maybe something in the networking or ZFS storage sub-systems. (This is going to be difficult to find!) Could you try the iscsi target with a non ZFS backing store, like a file on UFS, or a dedicated disk: http://www.cuddletech.com/blog/pivot/entry.php?id=779 http://www.c0t0d0s0.org/archives/4222-Less-known-Solaris-Features-iSCSI-Part-4-Alternative-backing-stores.html Another idea - Maybe we could use DTrace to see what system calls the target is making and somehow identify if some are taking an exceptional long time? I would need to research on how to do that... Yes, if you leave the system long enough, I think it will eventually complete any outstanding write operations. This is because the iscsi initiator, will do a recovery login, and then it will continue from where it left off and write some more data. The problem is those long pauses when the system plays dead will reduce the average write rate to a fraction of what it should be. But if you wait long enough, I'd not be surprised that it eventually completes. Oh, and what network cards, and switches are you using...? Many thanks Nigel Smith -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
