Date: Thu, 03 Nov 2022 20:56:03 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 267533] Zfs Multi-Modifier Protection trigger an activity check even if it is disabled Message-ID: <bug-267533-227-WmDNuyMbNG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-267533-227@https.bugs.freebsd.org/bugzilla/> References: <bug-267533-227@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=3D267533 --- Comment #3 from Mark Johnston <markj@FreeBSD.org> --- (In reply to Mathieu Schmitt from comment #2) >From what I can see, "MMP is disabled" means that the MMP timeout is 0. See the comment above the definition of ub_mmp_delay: 956 /* Maybe missing in uberblocks we read, but always written */ 957 uint64_t ub_mmp_magic; 958 /* 959 * If ub_mmp_delay =3D=3D 0 and ub_mmp_magic is valid, MMP is = off. 960 * Otherwise, nanosec since last MMP write. 961 */ 962 uint64_t ub_mmp_delay; When ub_mmp_magic is zero, i.e., we are upgrading from a version without MM= P, we use a default timeout. The "activity check", just reads an uberblock several times with a pause in between and verifies that the txg recorded in the uberblock does not increa= se.=20 If it increases, then something else is writing to the pool, and it must no= t be imported. In your case, the txg changed, so something [else] is writing to the pool, = so the check fails. The fact that ub_mmp_magic =3D=3D 0 is not relevant; the = txg should not be changing. Maybe it is indeed a kernel bug, somehow, but I believe the patch just hides it. >From what I can see, the "multihost" property mainly controls whether ZFS w= ill periodically write to the pool, to increase the chance that "zpool import" notices that the pool is active. --=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-267533-227-WmDNuyMbNG>