Tim Connors writes:
Note that `mv <tank/subvol1>/blbah <tank/subvol2>/foo` to different subvols on the same device still copies-then-deletes the data as if its a separate filesystem (it is - think of it just like lvms) despite the fact that it's all just shared storage in the one pool. Slightly inconvenient and surprising, but makes sense in a way (even if zfs could be convinced to mark a set of blocks from a file as changing its owner from subvol1 to subvol2, how do you teach `mv` that this inter-mount move is special?
GNU cp has --reflink which AIUI is extra magic for ZFS & btrfs users. It wouldn't really surprise me if there was extra magic for mv as well, though I doubt it would apply in this case (as you say, inter-device move). Under btrfs, if / is btrfs root and you make a subvol "opt", it'll be visible at /opt even if you forget to mount it. Maybe in that case, mv *is* that clever, if only by accident. Incidentally, I have this in my .bashrc: grep -q btrfs /proc/mounts && alias cp='cp --reflink=auto' (The grep is just because it's shorter than checking if cp is new enough to have --reflink.)