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.)
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
