Ray Clark wrote:
Dynamite!
I don't feel comfortable leaving things implicit. That is how misunderstandings happen.
It isn't implicit it is explicitly inherited that is how ZFS is designed
to (and does) work.
Would you please acknowlege that zfs send | zfs receive uses the checksum
setting on the receiving pool instead of preserving the checksum algorithm used
by the sending block?
For now it depends wither or not you pass -R to 'zfs send' or not.
Without the -R argument the send stream does not have any properties in
it so it will (by design) use those that would be used if the dataset
was created by 'zfs create'.
In the future there will be a distinction between the local and the
received values see the recently (yesterday) approved case PSARC/2009/510:
http://arc.opensolaris.org/caselog/PSARC/2009/510/20090924_tom.erickson
Lets look at how it works just now:
portellen:pts/2# zpool create dummy c7t3d0
portellen:pts/2# zfs create dummy/home
portellen:pts/2# cp /etc/profile /dummy/home
portellen:pts/2# zfs get checksum dummy/home
NAME PROPERTY VALUE SOURCE
dummy/home checksum on default
portellen:pts/2# zfs snapshot dummy/h...@1
portellen:pts/2# zfs set checksum=sha256 dummy
portellen:pts/2# zfs send dummy/h...@1 | zfs recv -F dummy/home.sha256
portellen:pts/2# zfs get checksum dummy/home.sha256
NAME PROPERTY VALUE SOURCE
dummy/home.sha256 checksum sha256 inherited from dummy
Now lets verify using zdb, we should have two plain file blocks
(/etc/profile fits in a single ZFS block) one from the original
dummy/home and one from the newly received home.sha256.
portellen:pts/2# zdb -vvv -S user:all dummy
0 2048 1 ZFS plain file fletcher4 uncompressed
8040e8f120:a2c635bc0556:73b5ba539e9699:3b4d66984ac9d6b4
0 2048 1 ZFS plain file SHA256 uncompressed
57f1e8168c58e8cf:3b20be148f57852e:f72ee8e66663358f:1bfae4ae0599577c
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
