This is a weird situation I've been tracking for a while, but I've now caught it twice now so I'm convinced it's not a fluke.

My setup:

Pool A: A pure NVME pool with 4x4tb drives in raid0. This has one unraid share on it. The share is configured with the zfs pool as the primary storage, and the secondary storage set to none. I use this share quite a bit for various tasks.

Pool B: 2x16tb spinning rust. This pool contains no unraid shares, and is not exposed to any docker containers. znapzend sends shapshots to it at midnight every night. I've confirmed this behavior with the znapzend log file, and by looking at snapshot data in zfs.

One would expect pool B to only spin up once a night, at midnight, for the snapshots to run. However, access to pool A will sometimes spin pool B up.

Normally I just randomly notice it spun up, but I've caught it doing it live twice now, doing the same specific thing. One of the jobs that writes to this disk occasionally produces invalid filenames (containing | characters). So every now and then I clean it up by opening the terminal, and running this exact sequence of commands:
 

root@jibril:~# cd /mnt/user/fast/hf/v3/
root@jibril:/mnt/user/fast/hf/v3# find -name '*|*' -print0 | sed -ze "p;s/|/-/g" | xargs -0 -n2 mv

the "fast" mount here is the share on pool A. Yet somehow this will sometimes spin up both disks on share B. It does not spin up array disks.

I can't find a rational explanation for this, and can only assume at this point that there's some underlying ZFS tomfoolery afoot.

To get in front of the common problem: No, I'm not running zfs master, or any other ZFS related plugins other than znapzend. I had suspected it might somehow be at fault so I killed the daemon before running the test the last time, and it still spin up pool B.

I was about to post diagnostics but ended up finding the root of the problem in the process: Unraid has somehow determined that the backip pool contains files that the primary pool also contains, and has linked them.

This is... extremely non-ideal. How do I prevent unraid from doing this? The share is set up with pool A as the primary storage with no secondary, so I don't understand what logic unraid is using to snoop pool B and make this determination.

Going to tentatively mark this as fixed, I did some jiggerypokery with my zfs backups so they don't share pool names. 

I think this exposes how fragile the exclusive access system is though, and there should probably be a way to force it on, especially now that you can have lots of tiny little purpose built pools. I don't want to worry that one of them might have a folder that shares a name with an unraid share, both for performance reasons and because suddenly having FUSE start smudging files together is a bug factory