Date: Fri, 17 Nov 2017 17:33:55 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 178473] gmultipath(8) needs to be smarter about errors Message-ID: <bug-178473-8-GgZe54Pd7p@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-178473-8@https.bugs.freebsd.org/bugzilla/> References: <bug-178473-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D178473 Richard Kunert <rkunert@wisc.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkunert@wisc.edu --- Comment #4 from Richard Kunert <rkunert@wisc.edu> --- I think what is needed is a gmultipath equivalent to the no_path_retry sett= ing in DM Multipath on Linux, which allows specifying the number of retries bef= ore the queue is released and the I/O fails. I assume that would allow ZFS to realize that something is wrong. Retrying forever is not always a rational = or useful behavior. no_path_retry: A numeric value for this attribute specifies the number of times the system should attempt to use a failed path before disabling queuing. A value of fail indicates immediate failure, without queuing. A value of queue indicates that queuing should not stop until the path is fixed. I just set up a new FreeBSD server with dual HBAs, dual SAS expander backplanes, etc., using gmultipath. I am on the verge of migrating the serv= er to Ubuntu and ZFS on Linux just to avoid this issue - particularly seeing t= hat it was reported years ago and there has been no movement. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-178473-8-GgZe54Pd7p>