In looking at your pastebin...
Scenario 1 deliberately causes data loss as a result of the forced import
[*]. No surprise there.
Scenario 2 also works as designed because you're forcing the data loss on
vda
Scenario 2 again causes data loss because of the forced import. Again, no
surprise there.
Scenario 3 I don't follow your process, can you share the full procedure?
Scenario 4 I don't understand why you create a pool named blacksite and
then import -f blacksite.
               The pool should already be imported. While it is possible to
import multiple pools with
               the same name, each pool needs to have a different guid.
Otherwise, there might be a
               bug lurking here.

[*] by forcing an import in read/write mode you've effectively forked the
pool into two pools,
each with their own timeline of changes -- but without changing the pool
guid. It will not be
possible to re-integrate the datasets on these two pools using zpool mirror
attach/detach.

Methinks you might be trying to do the old "split mirror for offsite
disaster recovery" plan
for which you should consider using `zpool split`
 -- richard


On Mon, Dec 20, 2021 at 11:06 PM openzfs via openzfs-developer <
developer@lists.open-zfs.org> wrote:

> Thanks Richard for explaining this. I have done a couple of tests some
> time ago (you can find these in this pastebin: https://8n1.org/20024/2eb4).
> Results from these tests were that even for vdevs that have newer data (and
> other data for that matter) than other vdevs, it does not guarantee that
> vdev will be picked as the source. And in a  2-way mirror there is only one
> vdev with the latest data / checksums. So, still not sure why this happens.
> *openzfs <https://openzfs.topicbox.com/latest>* / openzfs-developer / see
> discussions <https://openzfs.topicbox.com/groups/developer> + participants
> <https://openzfs.topicbox.com/groups/developer/members> + delivery options
> <https://openzfs.topicbox.com/groups/developer/subscription> Permalink
> <https://openzfs.topicbox.com/groups/developer/T7209b2fe172e98f1-M9103dec105590d3e260c8f6b>
>

------------------------------------------
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/T7209b2fe172e98f1-M2439279d1c81e6c12c853d7f
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription

Reply via email to