Date: Mon, 13 Dec 2021 09:30:50 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Alan Somers <asomers@freebsd.org>, FreeBSD User <freebsd@walstatt-de.de> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: CURRENT: ZFS freezes system beyond reboot Message-ID: <b4dbd4a9-3df0-e59f-f76d-95d7643fcb1b@FreeBSD.org> In-Reply-To: <CAOtMX2hjGJHqvmFDarQ=bCen_hXtkeOkZj4KuFEuSfiWCsu17Q@mail.gmail.com> References: <20211212102032.08af9689@jelly.fritz.box> <CAOtMX2hjGJHqvmFDarQ=bCen_hXtkeOkZj4KuFEuSfiWCsu17Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/12/2021 18:45, Alan Somers wrote:
> You need to look at what's causing those errors. What kind of disks
> are you using, with what HBA? It's not surprising that any access to
> ZFS hangs; that's what it's designed to do when a pool is suspended.
However, a pool does not have to be suspended on errors.
failmode property provides a couple of alternatives:
wait Blocks all I/O access until the device connectivity is
recovered and the errors are cleared. This is the
default behavior.
continue Returns EIO to any new write I/O requests but allows
reads to any of the remaining healthy devices. Any
write requests that have yet to be committed to disk
would be blocked.
panic Prints out a message to the console and generates a
system crash dump.
But neither does any magic.
The errors will still be there.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4dbd4a9-3df0-e59f-f76d-95d7643fcb1b>