Date: Tue, 29 Apr 2014 10:43:06 +0200 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org> To: Karl Pielorz <kpielorz_lst@tdx.co.uk> Cc: freebsd-scsi@freebsd.org Subject: Re: New iSCSI Stack in 10.x - Prevent hangs on a dead target? Message-ID: <19D13ADF-EAE2-4CF7-BA67-562444CA0E2A@FreeBSD.org> In-Reply-To: <FB27958FDF06CC60D0AC9611@study64.tdx.co.uk> References: <FB27958FDF06CC60D0AC9611@study64.tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Wiadomość napisana przez Karl Pielorz w dniu 28 kwi 2014, o godz. 23:17: > Hi, > > I've been setting up iSCSI with a couple of 10.x boxes recently (using the new iscsictl / ctld et'al). > > This seems to work well - but if I connect to a remote iSCSI target - and that host 'dies' I/O on the local /dev/daX device for that dead target just halts - for what seems to be 'indefinitely'. > > In /var/log/messages - I can see the system trying to reconnect (to the dead host) - but I can't see sign (or way of telling it) it to 'give up' and move on after some timeout. > > e.g. I have a bunch of iSCSI disks in use with ZFS - this works fine until the remote node dies (which takes half the disks with it). > > ZFS just halts all I/O then on the pool - until I do, e.g. 'iscsictl -R -p dead-host-ip'. > > Is there any way of setting this on either the initiator (or the target) - it looks like something like iSCSI Time2Retain might cover it - but I can't find anywhere to set that, or anything similar... In HEAD, there is "kern.iscsi.fail_on_disconnection" sysctl. It's supposed to be used with gmultipath or ZFS; it basically makes connection error result in IO error instead of "hang" until successful reconnection. The initiator will still try to reconnect; when it succeeds, the disk devices will reappear. Would that solve your problem?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19D13ADF-EAE2-4CF7-BA67-562444CA0E2A>
