Lxd: Option to configure the ZFS block size on volumes

[InsanePrawn]

Custom volumes on ZFS (both filesystems and zvols) should expose control of their recordsize or volblocksize properties respectively.
This is commonly used to "tune" (read: fix) performance of applications like databases on ZFS, where it can have a huge impact due to its COW nature.

[stgraber]

Yeah, should be easy enough to add a new ZFS-specific volume property.

volume.zfs.blocksize when configured on a POOL, zfs.blocksize when configured directly on a volume.

[TimRots]

volume.zfs.blocksize when configured on a POOL, zfs.blocksize when configured directly on a volume.

Isn't this the other way around?

[stgraber]

no

[stgraber]

On a pool, the config keys that will impact volumes are all prefixed with volume. whereas no such prefixing is needed on volume keys since they can only affect volumes :)

[TimRots]

Thank you for clearing this up @stgraber.
Would like to give this one a shot to implement.

Do you have some tips/guidance on this? I'm still getting familiar with the code base.

[stgraber]

The easiest is likely to based it off another option we have and look for that in the codebase.
In this case, I'd look for volume.zfs.use_refquota which is mentioned in:

• doc/storage.md
• lxd/storage_pools_config.go
• lxd/storage/utils.go
• lxd/storage/drivers/driver_zfs_volumes.go
• lxd/storage/drivers/driver_zfs.go
• scripts/bash/lxd-client

It's a bit different in that this one will take a size instead of a boolean and it doesn't apply during quotas but instead just at volume creation and update time, so should be a smaller delta than refquota.

@tomponline how difficult to you reckon it would be to get rid of those entries in lxd/storage_pools_config.go and lxd/storage/utils.go, only relying on the drivers to expose their pool and volume configs?

The current way we have things feels like a bit of layering violation, resulting from us having never fully completed the migration over to the new storage packages.

[tomponline]

@stgraber shouldnt be difficult, as we've already made provision for taking that out at some point.

I think this section is dead code now that all storage drivers are ported over: https://github.com/lxc/lxd/blob/master/lxd/storage/utils.go#L307-L344

Which means we could then get rid of https://github.com/lxc/lxd/blob/master/lxd/storage/utils.go#L296 entirely as its only called from one place anyway.

The storagePoolValidateConfig and storagePoolValidate are a bit more involved, they may need a generic storage.Validate() function being added that loads the driver internally and calls its .Validate() function before the DB record is created.

Shall I add a task in trello for this?

[tomponline]

@stgraber one thing I was a bit caution around was the use of storagePoolValidateConfig in the old patches for storage pool, as didn't want to interfere with the historical conversion process.

[stgraber]

Yeah, seems worth adding a card to clean things up when we have some time.

For things being used from patches, we can move what we must keep to patches_utils.go