Hi, nils: After internal discussion within initiator team. we had several question need you clarify. especially that we need your specificated use case that would persuade to make tunable. what's benefit and what's strong point that need to make that? also if we do decide to make it tunable, what's valid value range for those tunnable parameter?
ISCSI_DEFAULT_CONN_SHUTDOWN_TIMEOUT. This is used for gracefully shutdown TCP connection before iscsi session get destoried. ' If your target is down/unreachable for 180 secs, you'll get hard I/O errors on your filesystem or application, whatever is using the respective iSCSI LUN.' Yes, we will blocked there waiting connection resuming, but the function iscsi_conn_offline() is never called when iscsi target is down and unreachable. only when iscsi parameter changed or discovery method changed need relogin iscsi target that could this function happen. so the case you described here is not case to make us decide this parameter tunnable. ISCSI_DEFAULT_SESS_ENUM_TIMEOUT this is SCSI command such as reportlun, testunitready, sess_inquiry that initialized by iscsi itself to target side. initiator fill in USCSI cmd packet's uscsi_timeout filed. and transport to SD and is consumed by target side. in FC or other HBA driver, this field usually a fixed hardcoded value about 60 secs. would you quote a pratical test case or defect so that it would persuade to change it tunnable. ISCSI_DEFAULT_CMD_INTERNAL_TIMEOUT including NOP, ABORT, RESET, LOGOUT, LOGIN, TEXT iscsi command. this hardcoded parameter is almost the same usage as ISCSI_DEFAULT_SESS_ENUM_TIMEOUT. so propose of change this tunnable is also not strong. while ISCSI_DEFAULT_CONN_LOGIN_MIN maybe used together with ISCSI_DEFAULT_LOGIN_RETRY_DELAY and ISCSI_DEFAULT_LOGIN_POLLING_DELAY. that is used as time interval between each connection retry. and also I do not see any strong reason and benefit when change this tunnable. the last is ISCSI_DEFAULT_CONN_LOGIN_MAX which is really make sense when considering this thead's topic. We had already known CR6665245, 6497777, 6706418 can use this function, if we can change this to tunable, we can extend or shorten whole iscsi login time. for example using ZFS over iSCSI to mirror a couple of servers. if we can shorten login timout value from 180 second to 1~2 second, we can greatly shorten response time of ZFS and improve end user experience of iscsi. while for the scenario that network had long latency or some kind. we need to extend the timeout value of iscsi login, so that we can guarantee each iscsi session establishment with the possible risk of user himself sustain a longer waiting for iscsi. Add things tunnable is not so hard. but it make iscsi initiator frastructure not so easily expand. and make maintance work and consistent of old and new CLI quite hard. conclusion: Still need strong reason and real case to persuade us make all listed parameter tunnable. This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
