Assume a dataset will be used for storing ONLY photo and image files.
What are the best dataset configuration settings to use?
i think you can adjust the record size of the dataset according to the file size you want to storage in that, to increase performance
1 Like
By “record size” do you mean the logical sector size or physical sector size?
Sector size of the disks, the VDEV or the pool?
FreeBSD Mastery: ZFS indicates that when creating a pool, ZFS will set the POOL sector size to the largest sector size from amongst all pool member VDEVs. As I understand it, it is much better (performance-wise and for disk/provider longevity) for the POOL sector size to be bigger than the VDEV sector size rather than the other way around, but the best option is for the pool sector size to match the physical disk sector size and for all disks within pool member VDEVs to have identical physical sector sizes.
Would love to hear feedback on this…
Just use the defaults. Seriously. Yes, you could increase the record size (and no, that isn’t the sector size (logical or physical), which you can’t set on a per-dataset basis anyway; it’s the record size, which is set in a UI field called “record size”), but there’s no real reason to.
If you have a workload where you legitimately need dataset settings different from the defaults, you already know it. If you don’t know that and why you need to change something, the odds that you need to are minuscule.
2 Likes
In defense of large recordsize (i.e, 1 MiB), I use it for all my pure storage / archival datasets.
I have noticed a difference in performance, and there is less overhead, such as every 1 MiB of a file’s data needs only one checksum and pointer, whereas the same such file on a dataset with a 128 KiB recordsize needs eight.
If you’re not going to be routinely modifying such files in-place, then you needn’t worry about the “efficiency cost” or “write amplification” of large recordsizes.
Don’t worry about “What if I have a bunch of files smaller than 1 MiB on this media dataset?” The sole, single block will be saved at the nearest power-of-2, rounded up. For example, a file that is 220 KiB will be stored in a single block that is 256 KiB. [1]
Don’t worry about “record slack” at the end of the file’s last block. ZFS inline compression (of any form; ZLE, LZ4, ZSTD, etc) will crush the trailing zeros into nothing. Hence, you won’t suffer from wasted “padding” across many files.
Then shrunk back down to 220 KiB, thanks to inline compression. ↩︎
3 Likes
(sigh)…I am obsessing…and whilst doing so, delaying many, many other things…thank you.
There is also this.
Seems to me that if you’re using wide raidz you may want to increase record size too.
The record size is BEFORE compression right?
1 Like
Yes. But terms get confusing with ZFS. I honestly don’t think the ZFS developers themselves can even figure out their own words. 
One way to approach it mentally:
recordsize: The “rule” or “policy” for a dataset. Each chunk of data in a file must be this size.
block: The actual uncompressed, unencrypted chunk of data in RAM, used by applications. It is the size of the recordsize policy.
block-on-disk: The compressed (and encrypted) chunk of data on the storage device. Can be equal to or smaller than the actual block itself (as it would be seen in RAM).
The above does not take into account things like “setting a recordsize after you already saved some files,” or the potential efficiency of compression with the ashift-to-recordsize ratio, or the special small blocks for files small enough to fit in a single block smaller than the recordsize policy, or how inline compression makes “padding” at the end of the file’s last block a non-issue.
1 Like