Zvol receive removes properties on import
Mark Saad
nonesuch at longcount.org
Thu Feb 18 20:37:06 UTC 2016
All
I am not sure if this is a bug or if t his is intended. Here is my use
case. On 10-STABLE amd64, built last week. I have an application that
directly uses a zvol for storage. To make things easy to manage I depend
on the refreservation; I don't want to thin provision the zvol IE one with
out a refreservation . In 10-STABLE this is the default mode of operations
. The short version of the issue is this. When I send the zvol to another
server and import it, or send it to a file and delete the original and
reimport it locally I loose the refreservation . The newly imported /
received zvol is now thin provisioned, or better put has no space guarantee
on the zpool for the zvol I just imported.
On Freebsd 10-STABLE I do the following tasks
root at rangefinder:~ # zfs create -V 10G zroot/testvol
make my app do some work on /dev/zvol/zroot/testvol
make a few snapshots of this data
root at rangefinder:~ # zfs snapshot zroot/testvol at snap0 ...
Then I need to send the zvol to another server and work on it there . I
first check to see what props are set on the zvol
root at rangefinder:~ # zfs get all zroot/testvol
NAME PROPERTY VALUE SOURCE
zroot/testvol type volume -
zroot/testvol creation Thu Feb 18 20:13 2016 -
zroot/testvol used 10.3G -
zroot/testvol available 885G -
zroot/testvol referenced 64K -
zroot/testvol compressratio 1.00x -
zroot/testvol reservation none default
zroot/testvol volsize 10G local
zroot/testvol volblocksize 8K -
zroot/testvol checksum on default
zroot/testvol compression lz4 inherited from
zroot
zroot/testvol readonly off default
zroot/testvol copies 1 default
zroot/testvol refreservation 10.3G local
zroot/testvol primarycache all default
zroot/testvol secondarycache all default
zroot/testvol usedbysnapshots 0 -
zroot/testvol usedbydataset 64K -
zroot/testvol usedbychildren 0 -
zroot/testvol usedbyrefreservation 10.3G -
zroot/testvol logbias latency default
zroot/testvol dedup off default
zroot/testvol mlslabel -
zroot/testvol sync standard default
zroot/testvol refcompressratio 1.00x -
zroot/testvol written 64K -
zroot/testvol logicalused 30K -
zroot/testvol logicalreferenced 30K -
zroot/testvol volmode default default
zroot/testvol snapshot_limit none default
zroot/testvol snapshot_count none default
zroot/testvol redundant_metadata all default
I send it and re-import it on the other server
root at rangefinder:~ # zfs send zroot/testvol at snap3 |gzip -7 >
/archive/testvol at snap3.zvol.gz
root at rangefinder:~ # zfs destroy -r zroot/testvol
ssh magic ....
root at depthfinder:~ # gzcat /import/testvol at snap3.zvol.gz |zfs receive
zroot/testvol
Then I check the props on the new box to insure its all good .
root at depthfinder:~ # zfs get all zroot/testvol
NAME PROPERTY VALUE SOURCE
zroot/testvol type volume -
zroot/testvol creation Thu Feb 18 20:20 2016 -
zroot/testvol used 1.02G -
zroot/testvol available 883G -
zroot/testvol referenced 1.02G -
zroot/testvol compressratio 1.00x -
zroot/testvol reservation none default
zroot/testvol volsize 10G local
zroot/testvol volblocksize 8K -
zroot/testvol checksum on default
zroot/testvol compression lz4 inherited from
zroot
zroot/testvol readonly off default
zroot/testvol copies 1 default
zroot/testvol refreservation none default
zroot/testvol primarycache all default
zroot/testvol secondarycache all default
zroot/testvol usedbysnapshots 0 -
zroot/testvol usedbydataset 1.02G -
zroot/testvol usedbychildren 0 -
zroot/testvol usedbyrefreservation 0 -
zroot/testvol logbias latency default
zroot/testvol dedup off default
zroot/testvol mlslabel -
zroot/testvol sync standard default
zroot/testvol refcompressratio 1.00x -
zroot/testvol written 0 -
zroot/testvol logicalused 1.01G -
zroot/testvol logicalreferenced 1.01G -
zroot/testvol volmode default default
zroot/testvol snapshot_limit none default
zroot/testvol snapshot_count none default
However at this point I notice we no longer have a refreservation .
--
mark saad | nonesuch at longcount.org
More information about the freebsd-fs
mailing list