Hi everyone,
I recently installed a Proxmox VE Server on a zfs mirror (encrypted) and I use syncoid to replicate the main dataset where I store the volumes of the VMs and of the containers.
Everything works fine but the target uses more space than source. Here some data:
SOURCE
root@pve:~# zfs get all dpool/DATA/ctvmvols | grep used
dpool/DATA/ctvmvols used 115G -
dpool/DATA/ctvmvols usedbysnapshots 680K -
dpool/DATA/ctvmvols usedbydataset 328K -
dpool/DATA/ctvmvols usedbychildren 115G -
dpool/DATA/ctvmvols usedbyrefreservation 0B -
dpool/DATA/ctvmvols logicalused 116G -
TARGET
root@pve:~# zfs get all b1pool/DATA/dpool-data-ctvmvols-backups | grep used
b1pool/DATA/dpool-data-ctvmvols-backups used 130G -
b1pool/DATA/dpool-data-ctvmvols-backups usedbysnapshots 3.09M -
b1pool/DATA/dpool-data-ctvmvols-backups usedbydataset 736K -
b1pool/DATA/dpool-data-ctvmvols-backups usedbychildren 130G -
b1pool/DATA/dpool-data-ctvmvols-backups usedbyrefreservation 0B -
b1pool/DATA/dpool-data-ctvmvols-backups logicalused 116G -
The “logicalused” is the same for the source and the target. There is a little difference for the values “usedbysnapshots” and “usedbydataset” but “usedbychilden” is 15G bigger on the target (115 vs 130).
The number of the volumes in the datasets is the same and also the number of snapshots (498).
The “compressratio” for both the datasets is the same but multiple children have different “compressratio” values (don’t know why)
Maybe is important to note that I send the data encrypted and as “raw”. Here the cron command that is executed every hour:
root@pve:~# zpool status dpool ; zpool status b1pool
pool: dpool
state: ONLINE
scan: scrub repaired 0B in 00:00:24 with 0 errors on Sun Jan 12 00:24:26 2025
config:
NAME STATE READ WRITE CKSUM
dpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
6f58dfe3-22bb-4140-b23b-fb64855aece3 ONLINE 0 0 0
a3a8170d-58a4-624c-8570-9a8446b4fba0 ONLINE 0 0 0
errors: No known data errors
pool: b1pool
state: ONLINE
scan: scrub repaired 0B in 00:00:38 with 0 errors on Sun Jan 12 00:24:39 2025
config:
NAME STATE READ WRITE CKSUM
b1pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
4d9e6bbc-8385-f340-89f6-ab2639f0729d ONLINE 0 0 0
cfdc3ef3-a881-f34e-a23e-824392a14f58 ONLINE 0 0 0
errors: No known data errors
Interesting. How about ashift on each vdev involved?
Edit: hang on, this is proxmox… Which means ZVOLs. I suspect differences in refreservation settings, which are generally inherited from the parent on target rather than being set to match the source.
Check that on the specific child datasets where you see higher used on target than source, please!
root@pve:~# zpool get ashift
NAME PROPERTY VALUE SOURCE
b1pool ashift 12 local
dpool ashift 12 local
here I list all “refreservation”. I exclude “refreservation -” and “refreservation none”. It remains not so much and there is no difference:
root@pve:~# zfs get refreservation | grep -vP 'refreservation\s+-' | grep -v none
NAME PROPERTY VALUE SOURCE
b1pool/DATA/dpool-data-ctvmvols-backups/vm-100-disk-0 refreservation 125M received
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 refreservation 3M received
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-1 refreservation 16.3G received
dpool/DATA/ctvmvols/vm-100-disk-0 refreservation 125M local
dpool/DATA/ctvmvols/vm-101-disk-0 refreservation 3M local
dpool/DATA/ctvmvols/vm-101-disk-1 refreservation 16.3G local
Two of the datasets where there is a different compressratio are:
I don’t know what exactly is going on here, but these two datasets do not share a state. If they did, their logicalused and logicalreferenced would be identical, regardless of the “real” values on-disk.
Let’s see if we can figure out what’s going on with that, focusing on this particular volume. List the GUIDs of all snapshots of that volume on both source and target, like so:
root@box:# zfs get guid -t snap -r dpool/DATA/ctvmvols/vm-101-disk-0 ; zfs get guid -t snap -r b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0`
If the volumes share state, you’ll have an exact match of GUIDs all the way down, like this:
As you can see, I cut the first part of the names to better compare the results with vimdiff and I found no differences but I also compared the datasets again and the guid is different. I’m confused:
root@pve:/tmp# zfs get all dpool/DATA/ctvmvols/vm-101-disk-0
NAME PROPERTY VALUE SOURCE
dpool/DATA/ctvmvols/vm-101-disk-0 type volume -
dpool/DATA/ctvmvols/vm-101-disk-0 creation Tue Dec 24 8:54 2024 -
dpool/DATA/ctvmvols/vm-101-disk-0 used 3.72M -
dpool/DATA/ctvmvols/vm-101-disk-0 available 779G -
dpool/DATA/ctvmvols/vm-101-disk-0 referenced 232K -
dpool/DATA/ctvmvols/vm-101-disk-0 compressratio 2.21x -
dpool/DATA/ctvmvols/vm-101-disk-0 reservation none default
dpool/DATA/ctvmvols/vm-101-disk-0 volsize 1M local
dpool/DATA/ctvmvols/vm-101-disk-0 volblocksize 16K default
dpool/DATA/ctvmvols/vm-101-disk-0 checksum on default
dpool/DATA/ctvmvols/vm-101-disk-0 compression on default
dpool/DATA/ctvmvols/vm-101-disk-0 readonly off default
dpool/DATA/ctvmvols/vm-101-disk-0 createtxg 108140 -
dpool/DATA/ctvmvols/vm-101-disk-0 copies 1 default
dpool/DATA/ctvmvols/vm-101-disk-0 refreservation 3M local
dpool/DATA/ctvmvols/vm-101-disk-0 guid 2916268870370452825 -
dpool/DATA/ctvmvols/vm-101-disk-0 primarycache all default
dpool/DATA/ctvmvols/vm-101-disk-0 secondarycache all default
dpool/DATA/ctvmvols/vm-101-disk-0 usedbysnapshots 504K -
dpool/DATA/ctvmvols/vm-101-disk-0 usedbydataset 232K -
dpool/DATA/ctvmvols/vm-101-disk-0 usedbychildren 0B -
dpool/DATA/ctvmvols/vm-101-disk-0 usedbyrefreservation 3M -
dpool/DATA/ctvmvols/vm-101-disk-0 logbias latency default
dpool/DATA/ctvmvols/vm-101-disk-0 objsetid 10679 -
dpool/DATA/ctvmvols/vm-101-disk-0 dedup off default
dpool/DATA/ctvmvols/vm-101-disk-0 mlslabel none default
dpool/DATA/ctvmvols/vm-101-disk-0 sync standard default
dpool/DATA/ctvmvols/vm-101-disk-0 refcompressratio 3.17x -
dpool/DATA/ctvmvols/vm-101-disk-0 written 0 -
dpool/DATA/ctvmvols/vm-101-disk-0 logicalused 1020K -
dpool/DATA/ctvmvols/vm-101-disk-0 logicalreferenced 572K -
dpool/DATA/ctvmvols/vm-101-disk-0 volmode default default
dpool/DATA/ctvmvols/vm-101-disk-0 snapshot_limit none default
dpool/DATA/ctvmvols/vm-101-disk-0 snapshot_count none default
dpool/DATA/ctvmvols/vm-101-disk-0 snapdev hidden default
dpool/DATA/ctvmvols/vm-101-disk-0 context none default
dpool/DATA/ctvmvols/vm-101-disk-0 fscontext none default
dpool/DATA/ctvmvols/vm-101-disk-0 defcontext none default
dpool/DATA/ctvmvols/vm-101-disk-0 rootcontext none default
dpool/DATA/ctvmvols/vm-101-disk-0 redundant_metadata all default
dpool/DATA/ctvmvols/vm-101-disk-0 encryption aes-256-gcm -
dpool/DATA/ctvmvols/vm-101-disk-0 keylocation none default
dpool/DATA/ctvmvols/vm-101-disk-0 keyformat hex -
dpool/DATA/ctvmvols/vm-101-disk-0 pbkdf2iters 0 default
dpool/DATA/ctvmvols/vm-101-disk-0 encryptionroot dpool/DATA -
dpool/DATA/ctvmvols/vm-101-disk-0 keystatus available -
dpool/DATA/ctvmvols/vm-101-disk-0 snapshots_changed Tue Jan 28 14:00:41 2025 -
dpool/DATA/ctvmvols/vm-101-disk-0 prefetch all default
root@pve:/tmp# zfs get all b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0
NAME PROPERTY VALUE SOURCE
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 type volume -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 creation Mon Jan 20 15:38 2025 -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 used 6.83M -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 available 755G -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 referenced 816K -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 compressratio 1.51x -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 reservation none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 volsize 1M local
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 volblocksize 16K default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 checksum on default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 compression on default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 readonly off default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 createtxg 610646 -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 copies 1 default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 refreservation 3M received
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 guid 2325873904905528961 -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 primarycache all default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 secondarycache all default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 usedbysnapshots 3.03M -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 usedbydataset 816K -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 usedbychildren 0B -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 usedbyrefreservation 3M -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 logbias latency default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 objsetid 33112 -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 dedup off default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 mlslabel none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 sync standard default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 refcompressratio 2.55x -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 written 0 -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 logicalused 1.61M -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 logicalreferenced 644K -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 volmode default default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 snapshot_limit none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 snapshot_count none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 snapdev hidden default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 context none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 fscontext none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 defcontext none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 rootcontext none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 redundant_metadata all default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 encryption aes-256-gcm -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 keylocation none default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 keyformat hex -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 pbkdf2iters 0 default
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 encryptionroot b1pool/DATA/dpool-data-ctvmvols-backups -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 keystatus unavailable -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 snapshots_changed Tue Jan 28 14:15:03 2025 -
b1pool/DATA/dpool-data-ctvmvols-backups/vm-101-disk-0 prefetch all default
Maybe because the VMs write data (ex. logs) and the datasets are never the same? Although not a difference of about 25G (now).
edit: the whole difference is 25G but the difference between source and target of vm-101-disk-0 is about 3M (3.72M vs 6.83M)
To better understand what is going on, I have now destroyed the target pool and I copied the data again. The difference of “used space” is still there:
That’s quite a divergence of data, but maybe for serious amounts of data it’s no big deal. Usually these variations are from ashift differences or block size differences.
The empty dataset that’s the parent of those volumes doesn’t matter one way or another, only the volumes themselves.
I asked Allan Jude elsewhere about this, and his thought was perhaps, if the target volumes had never been mounted, that there were items still in the queue on the target side which had been completed on the source side, and that could cause a change in the reported free space at each location. I’m not entirely sure that makes sense, here, given that these are ZVOLs not filesystem datasets, but at this point I’m at a loss.
(With that said, I don’t use ZVOLs in production in the first place, which makes it entirely possible that there are zvol-specific factors in play that I’m unfamiliar with.)
@mercenary_sysadmin Thank you very much for your help and thanks to @allan
I have some questions to close the argument. I’m assuming you also use Proxmox and as you said you don’t use ZVOLs.
Do you use directories (zfs datasets used as directories) as Proxmox Storage instead of zfs storage?
If so, you can’t make Snapshots in Proxmox but you still can use sanoid and syncoid to create snapshots and send them to another pool. Right?
Do you use raw files? I should be able to convert ZVOLS to raw files (at the moment I’ve only found this post). Right?
Using the above setup, I then would be able to send encrypted data to a target, that can’t decrypt the data but it will maintain the same used space of the source. Right?
All these questions because I will change my setup, since I’d like to use something that I completely understand
If I made wrong assumptions, could you please describe how would you do the setup?
Sorry friend, I am not a proxmox user. I do a lot of virtualization on top of OpenZFS storage using the KVM hypervisor (the basic tools beneath proxmox) but I use them on vanilla Ubuntu.
Proxmox and I are both rather opinionated, and our opinions too frequently clash for me to be comfortable with it.
Now there’s a decision: qcow2 for full support of QEMU features like migration and hibernation, or raw for highest performance? It’s not the same decision every time, so one or the other of the following:
From here, I’m ready to fire up virt-manager to create the VM’s hardware definitions, and pull a graphical console to do the OS installation on it.
I do typically install a full desktop interface on my VM hosts, and virt-manager along with it, but that’s basically for emergencies only–my normal routine is connecting virt-manager running on my workstation to the server in question across virt-manager’s built in support for using SSH tunnels.
Inside a production environment, the SSH is generally all that’s needed. When controlling a host from OUTSIDE its local environment, I typically use WireGuard to get access to the local network of the host, then SSH, rather than exposing the host’s SSH daemon directly to the Internet.