Why are you subjecting the server jellyfin is on to 64x parity calculations for every read, and storing 64x the metadata on your multiple tb of media that is all bigger than a mb, just for a small db that is used by on average less than 5 users?
The whole example about vms, i just fundamentally disagree with for various reasons. it doen’t change the underlying idea that block/recordsize should be set according to the workload data size. I guess we disagree about the importance relevance of the jellyfin db.
if you have enough users that the db performance becomes an issue on the medias larger block size move the db to a different zvol or dataset with a more appropriate block/record size(its tiny compare to the media and can be esasily coppied move to a new dataset by comparison). But, this still doen’t change the two recomendations that media should be stored on zvol/datasets with large record sizes, and databases generally on smaller.
Once I have determined my file usage pattern what do I need to do on the config side? And secondarily how do I validate that I am doing the config in the right direction? Is it only that I’m getting better speeds, or are there other factors I should also look at?
Will give you a block size histogram of of a pool so you can see how much data is in different block sizes(will give you a count of a bock sizes along with space taken up by those blocks). Set the block size to maximize size while minimizing the amount of data in smaller blocks. The tricky part is knowing if certain data thats being used frequently is in a smaller block size.
The problem here is changing the setting does not retroactivly change the block size on existing blocks(data already in the pool) only new blocks written will be written following the new size.
Generally i find it best to do a test setup when building a new pool with my interned workload to see what the data will look like then recreate the pool based on my findings(sometimes i do multiple iterations) with the new setting before moving my data onto the new pool.
Note here zfs send and reciev send blocks in the origin pools size and plunk them in the destination pool without changing their size. So if your trying to change the block size of an existing pool the only way to do it is by copying the data off and back on with a non zfs tool.
Validating is testing your use-case, and verifying your performance is good, or better, than a different config.
What are you comparing here? Are you suggesting having a Jellyfin VM with a 1MiB volblocksize?
Either way, I could direct the question back at you. Why are you subjecting the server to more parity calculations and metadata by not using 16MiB for movies? Why are you limiting yourself to 64k?
Yeah, but what is the workload data size?
Sure it is 64k for MySQL (if you don’t use compression).
But what about the Ubuntu VM for Jellyfin?
Here are even better recommendations:
Media should be stored on dataset with huge record sizes.
DB can either be stored on zvols/datasets with a matching volblocksize without compression or with compression but then you won’t have a perfect match
VMs are a mixed workload and for 99% the 16k default is the perfect balance between compression, rw amplification, fragmentation, pool geometry
Sure you do. What if ZFS can compress your MariaDB 64k write to 38k? You no longer have a matching volblocksize.
The os only really does a lot of io at boot up, after its loaded in ram if you ever notice logging is about the only io ubunut server does. Almost all io will come from your applications. Assuming 99.999% uptime you should be booting maybe twice a year. Point here is i would not set a single zvol vm according to os needs, since the goal is not to need to reboot it, and my applications io is what is most important at runtime.
First it would be 64mb for 64x again. And Diminishing returns, and at bigger than 1mb now every time a drive does a single read, it has to read 64mb. Which would definitely hurt performance.
I’m not 16k is 1/64th of a 1mb block size. I was comparing the default you mentioned.
To 1mb.
Here are the other sizes i mentioned
note the … . in context i never specifically was talking about 64k. (64x (64 times) is not 64k)
No its not, its dependent on what you store in MySQL. if each entry is a string that is the length of a book then each entry is going to possibly be 1mb worth of text. You will want bigger than 64k for this. On the flip side if each entry is a single character then you will probably want 4k.
See above about why the ubuntu vm is not a workload!
This is worng db entrys are not a cookie cuter size, the data stored in the db determine the entry size. Point being you will rarely(try almost never) get a perfect matcch.
Already stated why i think this is wrong and disagree.
Again db’s do not write in fixed sizes stop with this misconception. If a db writes a int it writes 4bytes for that int.
So would you seriously suggest to run a Jellyfin VM on a 1MiB zvol? You can even set a zvol higher than 128k in TrueNAS
So do you suggest to set the zvol to 128K?
Then I ask you, why have 8 times the metadata? Why not use 1mb instead?
Well you are entitled to your own opinion.
But you have to ask yourself the question, why Proxmox uses 16k as default. Why ZFS uses 16k as default.
They moved the default from 8k to 16k in ZFS 2.2.
Why didn’t they move it to 128k?
Off topic stuff about DBs
To be honest, I don’t really know for sure nor do I really need high performance DBs. So that is not the hill for me to die on. But everything I ever read, said the opposite.
The ZFS default was 8k, because that was the default of some Oracle DB.
Everything in ZFS documentation sais that you should use 16k for MySQL.
Quote from MySQL manual:
Consider using a page size that matches the internal sector size of the disk. Early-generation SSD devices often have a 4KB sector size. Some newer devices have a 16KB sector size. The default InnoDB page size is 16KB. Keeping the page size close to the storage device block size minimizes the amount of unchanged data that is rewritten to disk.
In the end you can boil down all that technical shenanigans to some very simply basics.
zvol have a fixed blocksize while datasets have a max record size.
If you wan’t the best performance, don’t worry about pool geometry, don’t worry about fragmentation, don’t worry about rw amplification simply get:
a mirror zvol 16k for VMs
mirror or RAIDZ dataset with 128k - 16MB for data
If you do that, you will have a painless experience with ZFS. If not, YMMV.
