[Bug 267533] Zfs Multi-Modifier Protection trigger an activity check even if it is disabled

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.