Companion page to EVE-OS / ZEDEDA Application Volumes — covers what actually happens on the persist backend when you set a Max Size larger than the image, e.g. an 8 GB image with maxsize set to 100 GB.

• ext4 persist (qcow2 volumes): thin-provisioned. Setting a 100 GB maxsize on an 8 GB image does not immediately consume 100 GB of physical /persist space.
• ZFS persist (zvols): not confirmed. zvols are not thin-provisioned the same way qcow2 is by default — this needs verification against EVE's volumemgr behavior before relying on it for capacity planning.

qcow2 is a sparse container format. When EVE creates/resizes a drive's backing qcow2 file to a given maxsize:

• The file gets a virtual size equal to maxsize (e.g. 100 GiB).
• Actual bytes written to /persist start at roughly the size of the data copied in from the image (~8 GB) and grow only as the guest writes new data into the unused headroom.
• qemu-img info on the file would show virtual size: 100 GiB but a much smaller disk size: until the guest actually fills it in.
• This is default qcow2 behavior — it changes only if preallocation is explicitly forced to metadata, falloc, or full, which is not something exposed via the ZEDEDA GUI/Terraform maxsize/preserve fields covered in the companion page.

• A zvol created with zfs create -V 100G pool/vol reserves (refreservation) that space on the pool by default, unless created sparse with the -s flag.
• Whether EVE's volumemgr creates app-instance zvols sparse or with reservation is not confirmed from available docs/source at the time of writing.
• If zvols are created non-sparse, a 100 GB maxsize on a ZFS-persist node would reserve the full 100 GB against the pool immediately, unlike the ext4/qcow2 case above.
• Action item: verify directly against a test node (zfs get volsize,refreservation,used <pool>/<vol> after deploying a drive with headroom) before sizing decisions are made on any ZFS-persist deployment (e.g. Quvia nodes running raid1/raid5/raid6 persist).

• Admission control: the controller/EVE typically checks available persist capacity before allowing a deploy — it needs to believe the full maxsize *could* fit, even though actual usage will be much smaller initially. A deploy can fail a capacity check on a pool that doesn't have 100 GB free, even though real usage would only be ~8 GB.
• Guest visibility: regardless of host-side provisioning, the guest only sees/uses its original partition size until growpart/resize2fs (or the Windows equivalent) is run inside the guest — see the companion page's guest-side step.

• EVE-OS / ZEDEDA Application Volumes — drive types, maxsize/preserve/allow_storage_resize, deploy and grow steps.
• EVE-OS Partitioning / ZFS page (persist backend, RAID levels, ZFS overhead) — physical-layer capacity planning; this page covers the logical/per-drive layer above it.