Project

General

Profile

Bug #7998

zfs volumes sometimes grow on copying

Added by Michael Mounteney over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2017-03-22
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Likely as a consequence of fixing [[https://illumos.org/issues/6562]] and [[https://illumos.org/issues/4986]], a volume can grow when copied from one zpool to another.

Example: copying a 2GiB volume from pool woz to pool vault. First verify that the effect is not caused by spurious snapshots:

root# zfs list -t all -r woz/vol/Linuswap-KDE
NAME                   USED  AVAIL  REFER  MOUNTPOINT
woz/vol/Linuswap-KDE  2.03G  80.9G  2.03G  -

Then copy the volume (note change in destination name as vault/vol/Linuswap already exists and is in use):

root# zfs snapshot woz/vol/Linuswap-KDE@Z ; zfs send -R woz/vol/Linuswap-KDE@Z | zfs recv vault/vol/LSwap

Then observe that the copy is approximately 50% larger than the original:

root# zfs list -t all -r vault/vol/LSwap     
NAME                USED  AVAIL  REFER  MOUNTPOINT
vault/vol/LSwap    2.95G   474G  2.95G  -
vault/vol/LSwap@Z      0      -  2.95G  -

It shouldn't matter on a volume anyway, but this is not explained by zpool block size. ashift=12 on both pools.

Properties of original and copied volumes:

root# zfs get all woz/vol/Linuswap-KDE
NAME                  PROPERTY              VALUE                  SOURCE
woz/vol/Linuswap-KDE  type                  volume                 -
woz/vol/Linuswap-KDE  creation              Fri Mar 17  3:47 2017  -
woz/vol/Linuswap-KDE  used                  2.03G                  -
woz/vol/Linuswap-KDE  available             80.9G                  -
woz/vol/Linuswap-KDE  referenced            2.03G                  -
woz/vol/Linuswap-KDE  compressratio         1.00x                  -
woz/vol/Linuswap-KDE  reservation           none                   default
woz/vol/Linuswap-KDE  volsize               2G                     local
woz/vol/Linuswap-KDE  volblocksize          8K                     -
woz/vol/Linuswap-KDE  checksum              on                     default
woz/vol/Linuswap-KDE  compression           off                    default
woz/vol/Linuswap-KDE  readonly              off                    default
woz/vol/Linuswap-KDE  copies                1                      default
woz/vol/Linuswap-KDE  refreservation        none                   default
woz/vol/Linuswap-KDE  primarycache          all                    default
woz/vol/Linuswap-KDE  secondarycache        all                    default
woz/vol/Linuswap-KDE  usedbysnapshots       0                      -
woz/vol/Linuswap-KDE  usedbydataset         2.03G                  -
woz/vol/Linuswap-KDE  usedbychildren        0                      -
woz/vol/Linuswap-KDE  usedbyrefreservation  0                      -
woz/vol/Linuswap-KDE  logbias               latency                default
woz/vol/Linuswap-KDE  dedup                 off                    default
woz/vol/Linuswap-KDE  mlslabel              none                   default
woz/vol/Linuswap-KDE  sync                  disabled               inherited from woz/vol
woz/vol/Linuswap-KDE  refcompressratio      1.00x                  -
woz/vol/Linuswap-KDE  written               0                      -
woz/vol/Linuswap-KDE  logicalused           2.01G                  -
woz/vol/Linuswap-KDE  logicalreferenced     2.01G                  -
woz/vol/Linuswap-KDE  snapshot_limit        none                   default
woz/vol/Linuswap-KDE  snapshot_count        none                   default
woz/vol/Linuswap-KDE  redundant_metadata    all                    default
root# zfs get all vault/vol/LSwap
NAME             PROPERTY              VALUE                  SOURCE
vault/vol/LSwap  type                  volume                 -
vault/vol/LSwap  creation              Thu Mar 23  7:28 2017  -
vault/vol/LSwap  used                  2.95G                  -
vault/vol/LSwap  available             474G                   -
vault/vol/LSwap  referenced            2.95G                  -
vault/vol/LSwap  compressratio         1.00x                  -
vault/vol/LSwap  reservation           none                   default
vault/vol/LSwap  volsize               2G                     local
vault/vol/LSwap  volblocksize          8K                     -
vault/vol/LSwap  checksum              on                     default
vault/vol/LSwap  compression           off                    default
vault/vol/LSwap  readonly              off                    default
vault/vol/LSwap  copies                1                      default
vault/vol/LSwap  refreservation        none                   default
vault/vol/LSwap  primarycache          all                    default
vault/vol/LSwap  secondarycache        all                    default
vault/vol/LSwap  usedbysnapshots       0                      -
vault/vol/LSwap  usedbydataset         2.95G                  -
vault/vol/LSwap  usedbychildren        0                      -
vault/vol/LSwap  usedbyrefreservation  0                      -
vault/vol/LSwap  logbias               latency                default
vault/vol/LSwap  dedup                 off                    default
vault/vol/LSwap  mlslabel              none                   default
vault/vol/LSwap  sync                  disabled               inherited from vault/vol
vault/vol/LSwap  refcompressratio      1.00x                  -
vault/vol/LSwap  written               0                      -
vault/vol/LSwap  logicalused           2.01G                  -
vault/vol/LSwap  logicalreferenced     2.01G                  -
vault/vol/LSwap  snapshot_limit        none                   default
vault/vol/LSwap  snapshot_count        none                   default
vault/vol/LSwap  redundant_metadata    all                    default

Related issues

Related to illumos gate - Bug #6562: Refquota on receive doesn't account for overageClosed2016-01-18

Actions
Related to illumos gate - Bug #4986: receiving replication stream fails if any snapshot exceeds refquotaClosed2014-07-10

Actions

History

#1

Updated by Michael Mounteney over 2 years ago

  • Related to Bug #6562: Refquota on receive doesn't account for overage added
#2

Updated by Michael Mounteney over 2 years ago

  • Related to Bug #4986: receiving replication stream fails if any snapshot exceeds refquota added
#3

Updated by Michael Mounteney over 2 years ago

It is significant that in the example given above, the source zpool woz is a single disk, and the destination vault is a four-disk raidz2 zpool.

Also available in: Atom PDF