@ahrens I don't know if we are, and I think it's unlikely. But since master is
clearly wrong and can cause easily reproducible panic on every platform with a
single zfs create in a pool without the new feature flag flipped on, I'm at a
loss for what exactly would cause the tests to fail IF they are actually known
to pass elsewhere in equivalent environments. I'm thinking it's quite likely
that either a) the environment in which the tests for this PR run is somehow
different from the known passing environments, or b) the environments for other
PRs are indeed equivalent and also fail (with that failure possibly unnoticed
or undetected?).
So I'm wishfully hoping it could be as simple as something unexpectedly hitting
that verify. Of course, the "scariest" explanation would be if somehow this PR
is revealing a bug with the new dedup checksums themselves, though I think
that, too, is unlikely.
In any case, illumos HEAD is basically unreleasable right now due to this bug
since <code>zfs create -o dedup=S,verify tank/foo</code> is enough to send any
system into an "endless" panic-reboot-panic-reboot loop if the system has any
preexisting pool tank with an S in {edonr, sha512, skein} such that feature@S
has not been explicitly enabled on tank. The system and pool are, of course,
fixable once someone figures out what went wrong, but that's beside the point.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/51#issuecomment-173136666_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
