Ben - ZFS Copy

Good afternoon both,

Thanks so much for such a great show, it’s the highlight of my week, and after eight months you’ve helped me get closer to the community and made me excited about FreeBSD.

A few weeks ago I upgraded my FreeBSD 10.2 server up to 10.3, but I did the upgrade on a new boot environment and was pleasantly surprised to see it work.  It was a feature of OpenSolaris I loved back when I was using it daily, and having moved away from IT for a bit and coming back, it brings back fond memories.
I was talking to a friend about the upgrade and we were commenting on how the boot environment allows you to roll the system back should an upgrade go sour, and then my friend asked me “what about your data?  What happens if you notice an odd update quirk a week later and roll back, what happens to your data?”  A quick look suggests that the boot environment only snapshots the root FS, and other ZFSs were untouched.  I commented that since ZFS was cheap you could afford to have a lot of them and he came back saying that they were cheap until you needed to move large files between them.

This got me thinking, if two ZFS datasets are in the same pool, sharing the same storage, and you move a file between them; why does it take so long?  (Moving 2GB of random data between $HOME and /var/tmp on my laptop takes ~15seconds, both datasets reside in the same pool on the same disk; 20GB took 8 minutes)
Do ZFS datasets have boundaries similar to partitions?  My immediate thought was no, and that surely only a new inode would need to be created in the new dataset and then just pointed to where the data already is…?

I suppose the ultimate question may be: does Allan cover this kind of stuff in either of his books and is this another reason I need to hurry up and buy them?

Many thanks for your continuing enthusiasm and wisdom,

Ben / forquare