well make sense to those zfs experts who initially said that if the storage reaches 85% of it's limits becomes slow and if it reaches 92% becomes unstable. Not my words. I just try to avoid future problems here according to what I ma reading not from plain users but pros of the zfs architecture. After that I was going to make a custom guide according to my needs and if my eye caught to a similar question to help to the degree I can. After all isnt that the purpose of forums in general, helping not re invent the wheel? Imagine how many intermediate replies would have been avoided if more experienced users answered ... oh here is the link read and afterwards users that originally made the post returnign back asking the same question since to understand the man pages some times if not all the times you need a manual for the manual itself
you got pool and dataset levels confused. getting a pool full above a certain threshold will absolutely trash performance (just like approaching 100% actual memory usage will slow down allocations, because the effort to find big enough chunks gets higher or data needs to be fragmented if there are none). getting a dataset 100% full is not a problem (as long as the pool itself still has available space) - except of course that you can't write more data to it anymore once it's full.
a dataset pool/foo mounted on /pool/foo that contains a sub-directory called 'bar', without that 'bar' being a separate dataset.
Can this bar though be used on the GUI / Storage /Add Storage to create Directory and to the mount point to type /pool/foo/bar if you want to store something inside there or Proxmox will consider valid only the path pool/foo
not on the GUI, but on the CLI it is possible (set path to /pool/foo/bar, and is_mountpoint to /pool/foo, and PVE will wait for something being mounted on /pool/foo before considering the /pool/foo/bar storage activatable)
without 1 at the end because it assumes it? And without mkdir 0 above the line you say?
yes (or see above if your storage path and mountpoint are not the same)
My initial post started with/: Assuming I have created a zpool (zvolume) of 2Tb with name HH and inside there I need to create a Dataset for proxmox with name bckup and capacity of 500G to have space for VM/LXC backups.
So how can HH cant be a zvol? I created from GUI->pve node->disks giving it a name.
Now if proxmox automatically creates with a zvol a dataset as well with the same name that is something I never came across as knowledge
okay, now I see where the confusion comes from
a zpool is not the same as a (ZFS) volume/zvol!
in ZFS the terminology is as follows:
- vdev: a block device or raw image file used to store ZFS pool data (in LVM, this would roughly be a PV)
- zpool: a collection of vdevs + redundancy scheme and/or allocation class (in LVM, this would roughly be a VG)
- dataset: either a filesystem or zvol stored on a pool (this does not really exist in LVM, as LVM doesn't manage hierarchies of file systems but just volumes)
- zvol: a special kind of leaf dataset, can't have children, doesn't use the filesystem part of ZFS to store data, but is exposed as block device instead (in LVM, this would roughly be a LV)
so vdevs and pools are how the data is stored/organized physically on disk(s) (where, and distributed how?). datasets including zvols are how the data is logically stored (hierarchy of datasets containing either filesystems or logical block device data). one is managed with the 'zpool' command, the other with the 'zfs' command.
in PVE we use regular filesystem datasets for containers, and zvols for VMs. if you use the installer to install a system with / on ZFS, we also use regular filesystem datasets to store the system data, including setting up a directory storage on top of ZFS.
when you create a zpool, you automatically also create the root dataset for that pool (with the same name). that dataset can never be a zvol.
By the way
Can an existing dataset grow just by setting option quota to a bigger number?
for filesystem datasets, yes, you can arbitrarily set the quota lower or higher or even unset it to lift the restriction altogether. note that there are different kinds of quotas (like quota vs refquota, but also user/groupquota vs userobj/groupobjquota - please see the manpage for details!). PVE sets up refquotas for container volumes (as we want to use the quota for the size of the filesystem as exposed to the container, and don't want snapshots to count against the quota like they would with the regular 'quota' property).
for zvols it's a bit more complicated - they always need a (vol)size, so that determines how big the exposed block device is. a corresponding refreservation is set by default to ensure all that space is also available. if you set the 'thin provisioning' flag, no such reservation will be made, and you (or the VM) can run out of space on the zvol, leading to I/O errors. you can change the volsize (which will by default also change the refreservation), but you also have to ensure that the filesystem/partition table stored on the zvol is adapted accordingly, especially when shrinking the zvol.
