[Bug 267533] Zfs Multi-Modifier Protection trigger an activity check even if it is disabled
Date: Thu, 03 Nov 2022 20:56:03 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267533 --- 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 == 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 MMP, 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 increase. If it increases, then something else is writing to the pool, and it must not 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 == 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 will periodically write to the pool, to increase the chance that "zpool import" notices that the pool is active. -- You are receiving this mail because: You are the assignee for the bug.