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