I'm not too sure exactly what is going on here for your precise situation. But my guess is your zvol block size has some bearing on what is going on. Check out
https://bugs.freenas.org/issues/2383 .
As you can see, its possible for 100GB of test data with a 512byte block will take up 2.31TB(yes, TB) of disk space. It has to do with how ZFS works and it isn't a bug from what I've read about ZFS' file structure.
Cyberjock, I can confirm, it's the exactly same situation...
Any ideia or suggestion on how to fix this? We have 12TB free on the zpool, so moving 3TB of data is easy.
Should we abandon ZVOL wheres possible?
Recreate the ZVOL with another block size?
We have a 10x3TB Seagate SATA Disks in RAID-Z2, the ZVOL act as iSCSI with LVM from XenServer.
Thanks in advance,
PS: Some data...
Code:
storagepool1/lvm1 type volume -
storagepool1/lvm1 creation Fri Aug 30 20:57 2013 -
storagepool1/lvm1 used 8.42T -
storagepool1/lvm1 available 12.0T -
storagepool1/lvm1 referenced 8.42T -
storagepool1/lvm1 compressratio 1.00x -
storagepool1/lvm1 reservation none default
storagepool1/lvm1 volsize 5T local
storagepool1/lvm1 volblocksize 8K -
storagepool1/lvm1 checksum on default
storagepool1/lvm1 compression off default
storagepool1/lvm1 readonly off default
storagepool1/lvm1 copies 1 default
storagepool1/lvm1 refreservation 5.16T local
storagepool1/lvm1 primarycache all default
storagepool1/lvm1 secondarycache all default
storagepool1/lvm1 usedbysnapshots 0 -
storagepool1/lvm1 usedbydataset 8.42T -
storagepool1/lvm1 usedbychildren 0 -
storagepool1/lvm1 usedbyrefreservation 0 -
storagepool1/lvm1 logbias latency default
storagepool1/lvm1 dedup off inherited from storagepool1
storagepool1/lvm1 mlslabel -
storagepool1/lvm1 sync always inherited from storagepool1
storagepool1/lvm1 refcompressratio 1.00x -
storagepool1/lvm1 written 8.42T -