Date: Thu, 30 Nov 2023 00:04:53 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 275308] EN tracking issue for potential ZFS data corruption Message-ID: <bug-275308-3630-sM0DkAiEps@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275308-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-275308-3630@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=3D275308 --- Comment #20 from Rob Norris <robn@despairlabs.com> --- (In reply to Troels Just from comment #17) > would it be beneficial to do "zpool create ... -o feature@block_cloning= =3Ddisabled" ? Does that provide any benefit over the sysctl you mentioned? Disabling the feature makes the pool unable to clone blocks at all when ask= ed to do so. Disabling the sysctl makes it impossible to ask at all. On the sa= me system its much of a muchness, but if you move pools to other systems, that= may make a difference - the pool feature state will move with the pool, but the sysctl is bound to the host. > Is [#15333 about ZFS on LUKS] is in any way applicable on FreeBSD when ru= nning ZFS on top of GELI? No, totally unrelated. (In reply to Anderson Guzman from comment #19) > [2.2] dmu_buf_will_clone: fix race in transition back to NOFILL Its the fix for the cloning lock bug I mentioned right at the start, but we think there are still cloning bugs around. Cloning will remain disabled in 2.2.x for now. --=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-275308-3630-sM0DkAiEps>