So while planning my data layout I came across the realisation that these 2 datasets inherit their recordsize from the root dataset which for me is currently set at 128KiB.
.truenas_containers
ix-apps (and this does not seem a period)
So these are my thoughts
So for app and container writes 128KiB blocks is very large.
The default 128KiB is the recommended default recordsize for datasets so this is probably a good value to leave for the root dataset where the rest inherit from.
I will have more than apps and containers on this pool. Unless this is a really bad idea.
The issue
Without using the command line, which I should not have to because of how TrueNAS is supposed to work, how can I give these datasets a better recordsize
Can someone recommend me a suitable block size?
Is this a design flaw that needs to be flagged to the TN team?
I would say when you first initialise the apps and containers you have the options to set a recordsize. perhaps even change it later.
Apps and Containers do not have their recordsize optimized or the ability to change it unless you use the command line which should not be a recommendations for user level feature.
Proposed Feature
Enable the ability to set the recordsize for
ix-apps
When host paths are not used, TrueNAS should set the correct dataset recordsize for the child datasets of the app.
I am under the impression that you don’t understand that unlike block size of zvol, which is a static value, record size for datasets is a max value. That is why there is almost no downside of having a 128k record size for only 4k files.
If the file is smaller than or equal to recordsize, it’s stored as a single logical block of its size, rounded up to the nearest multiple of 512 bytes.
If the file is larger than recordsize, it’s split into multiple logical blocks of recordsize each, with the last block being zero-padded to recordsize.
So when you want to edit part of a file you have to read and write the whole block. This comes into play with database files which can be gigabytes in size but you can make a smaller edit if you blocks are 16K and not 128K.
Not all host paths for apps are hosting regular files.
When it comes to things other than VMs and databases and the uncommon software that does true in-place modifications on files, then it’s not wrong at all.
What are these database files you’re referring to? Immich, Plex, Jellyfin? How often are they modified and how badly does that really affect the pool? (Having to write and consume 128 KiB for a modification of only 16 KiB won’t really be noticed by most users.)
You do have a point for these specific cases, but I think iX doesn’t want people to become confused or shoot themselves in the foot trying to play with granular dataset settings for every single app.
EDIT: There’s the command-line in the meantime, but as you said before, you don’t want to have to resort to it since it goes against the “appliance” nature of the NAS. I doubt this feature or the other feature will be accepted by iX. They err towards fewer options for the sake of predictability and support.
EDIT 2: @dan brought up host paths, which makes this a moot point for some apps, since you can assign and configure a separate dataset with the preferred recordsize to store the app’s library or database.
Is this really something that needs to be fixed? I can’t imagine any reasonable scenario for a home/SOHO user (because I can’t imagine any reasonable enterprise using apps) that would be impacted in any real way with having recordsize at 128Kb
I guess if you’re running a database from your app pool? Maybe? Even then that seems more like a user error. (I’m not counting something like Immich or Plex DB; that just doesn’t hit the load to qualify)
I’m also confused by the logic that nothing should ever be done from CLI. If you really do have a special need that isn’t in the GUI, what else are you going to do? Imagine if every possible option/tuneable was in the GUI; nothing would ever be found in any reasonable amount of time.
I’m also wondering if it was actually inherited vs if 128Kb is just the default (not that it really matters in this case I guess).
You can’t control what goes on a vdev; you control what goes on a dataset. Your misuse of the terminology doesn’t speak well of your understanding of the underlying concepts.
If you’re asking questions like this, it doesn’t speak well of this being a well-thought-out feature request.
Host paths should pretty much always be used.
The phrase “tempest in a teapot” comes to mind, but I think that understates what’s going on here, and with your other two FR threads.
It certainly isn’t a natural typo, but sure, these things happen. If this were the only issue, I wouldn’t have mentioned it. But the other things I pointed out in this FR, as well as discussion in your other threads, strongly suggest a deep-seated misunderstanding of how things work, combined with an unwillingness to take simple steps to accomplish your goals.
Any signficant data for apps should be mounted via a host path. And if you take that simple step, your issue goes away, because that host path can be wherever you like, with whichever ZFS properties you like.
The same is true of containers–if they need to use or store any significant amount of data, that should be in an external mount to the container. Again, you’re free to set whatever ZFS properties you like for that.
For VMs, you can’t mount external storage in the same way, but you can choose where the zvol will be stored–which again gives you the same ability.
Not only that, but it prevents your libraries and databases from being lost if you remove the app. Putting aside recordsize and write-amplification, this should be done anyways.
Fair & I do appreciate the confirmation as it is additional knowledge.
That being said, I still think this is a mountains vs molehills issue in regards to DB performance needs in regards to the scope of how hard any SOHO app DB will be hit.
That is totally correct. That is exactly why 128k is a good default. You even can handle a Jellyfin or whatever 16k DB write. Sure it has amplification, but who cares, this isn’t a production DB that gets actually used a lot.
