As with everything, it depends on a number of variables, including:
Underlying pool layout (raidz3 does not play nicely in terms of space with small volblocksize or recordsize)
Desired compression performance (likewise small volblock/recordsize makes this difficult) - less of an issue if your guest does compression and you disable compression on the backing store
I/O patterns. DBs want to operate in small records. Mismatching the volblocksize or recordsize with this to improve the first two hit back with a RMW multiplier. But how much this is an issue also depends on what FS the guest is running in the volume.
At some level, every FS is a db, and expects to operate on the device with some sector size. The RMW penalty hits here, too, especially for small files.
End of the day, test with your workload. A database or system with lots of small files will benefit from smaller volblocksize and may be a better fit for a zvol. A guest that mainly stores large files that are not modified often won’t care much either way.
Converting back and forth between the two isn’t that difficult (provided the free space is available.) Fire up a VM and test with your workload.
fyi, https://openzfs.github.io/openzfs-docs/Performance and Tuning/Workload Tuning.html
Eg influxdb -> recordsize of 64K ; postgresql&mariadb -> of recordsize of 16K ; pouderiere -> recordsize ok 32K because compiling many small files. For all the rest -> recordsize 128K. And "atime off".
I dont know interworking of virtualisation & compression.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.