@roysk The thing about inquiry data is that it's incumbent on the target to provide what the initiator has asked of it. What is open-iscsi connecting to, another SAN, if so which make and model? If it's not a HW SAN could you setup an software iSCSI target server and connect with the existing open-iscsi tool set to see if the short inquiry phenomenon follows the SAN or the the client?
In my experience, these sort of faults usually are the result of a SCSI target that's not quite ready. Sure it may be fully provisioned, but if the SAN is busy serving other requests, *it's operating system* can starve out the target and cause unpredictable results. It's an equal opportunity offender, affecting software iSCSI targets and inefficient HW SAN firmware (also software :). Getting 36 bytes of inquiry data is trivial, something is really wrong if we can't get even that from the target. https://en.wikipedia.org/wiki/SCSI_Inquiry_Command If you are using a software target to begin with, consider adding cgroups to ensure it has a minimum of CPU time to perform it's tasks in a timely manner; or simply decreasing the net workload on the system and see if that improves reliability. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1034015 Title: Fails to connect to iSCSI target To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1034015/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
