Hello all,

  In the past days I've been doing some migration and reorganization
of datasets (VM images, local zones and stuff), and in the process I
used both dataset cloning and zfs-send|zfs-recv within the pool.
This is on the old SXCE snv_117, so things might have got better in OI.

  As one of the goals of the data reorganization was to enforce some
different compression (i.e. gzip-9 for data which was not touched for
a long time, or for the golden-images of VMs/zones), I tracked the
dataset attribute changes whenever a new dataset was spawned.

  It seems that changeable attributes such as compression are inherited
from the new parent dataset during cloning, however they are enforced
from the original dataset's values when I do a replication send (with
"zfs send -R"). That is, if I had a gzip-9 compressed golden VM cloned
into a pool hierarchy branch with different compression (off or lzjb),
the new cloned dataset by default inherits this different compression
setting; if I want it to remain gzip-9 - I have to do that explicitly.

  Is this by design? Does a snapshot which is the origin "know" of any
such settings, so it can provide them to children in the first place -
it seems to be so during replication-sends (though "zfs send" might
query the live dataset instead)?
  Is it so in the current ZFS versions as well?

  One of the reasons I ask is because of my RFE to support hierarchical
root filesystems in OI ( https://www.illumos.org/issues/829 ), which
for the most part works out of the box (with some manual procedures)
and allows to compress most of the FS with the bootloader not liking
compressed roots; however cloned BEs' datasets become uncompressed
by ZFS inheritance and thus the added value of the hierarchy is soon
negligible (as BE clones often occur during updates, and the new
software image is written to disk without compression).

  I wonder if it is possible to augment "zfs clone" with an option
to replicate origin's changeable attributes (all and/or a list of
ones we want), and use this feature in beadm?

//Jim Klimov

zfs-discuss mailing list

Reply via email to