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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178473 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 setting in DM Multipath on Linux, which allows specifying the number of retries before 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 server to Ubuntu and ZFS on Linux just to avoid this issue - particularly seeing that it was reported years ago and there has been no movement. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-178473-8-GgZe54Pd7p>