Date: Sat, 20 Jun 2015 14:06:20 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-questions@freebsd.org Subject: Re: ZFS passdevgonecb Message-ID: <1eed7432.7767d020@fabiankeil.de> In-Reply-To: <5583D5BE.7050508@herveybayaustralia.com.au> References: <557F90DB.80601@herveybayaustralia.com.au> <mlshi7$3of$1@ger.gmane.org> <5583D5BE.7050508@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/Y=DN+eZurnW1TRUtIPB.uQi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Da Rock <freebsd-questions@herveybayaustralia.com.au> wrote: > First, that ggatel and mountver workaround - how does zfs take that? If the workaround works, inflight requests will be delayed but other than that ZFS shouldn't notice the temporary device loss. > Is=20 > it possible zfs will have a dummy spit if this is between it writing to=20 > the drive? I'd assume not given it can use a md device as a vnode, but=20 > doesn't hurt to ask. If gmountver does not accept the reappearing device and you do not disable the ident checking as a (somewhat risky) workaround, this should eventually trigger a "stalled ZFS I/O" panic unless you set vfs.zfs.deadman_enabled=3D0 for testing or reboot the system before the expiration time. In my experience ZFS has lots of strange and surprising failure modes if devices act up, so I wouldn't completely rule out any other behaviour either ... Fabian --Sig_/Y=DN+eZurnW1TRUtIPB.uQi Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWFVzkACgkQBYqIVf93VJ2yEwCgvpbxObvZEC/Xttztf56WJWZW ARUAnAt9I82zzvb4PzyCoSMYlu2Ys2rE =b4au -----END PGP SIGNATURE----- --Sig_/Y=DN+eZurnW1TRUtIPB.uQi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1eed7432.7767d020>