SLOG: The partition layout won't matter unless you do
zfs set sync=always poolname/zvol - without this, your SLOG device, partition or full drive, won't be used at all. They will work better if the drive isn't shared between
cache and
log workloads, but the drives aren't good candidates for SLOG use either; you can see the throughput of an 850 Pro at various recordsizes here:
https://forums.freenas.org/index.ph...inding-the-best-slog.63521/page-5#post-486067
They'd be fine for L2ARC; if you've had your system running for a while and given it a chance to warm the cache, you could run
arc_summary.py from a command line which should give you some insight into how much is actually being used.
(And remember, "SLOG" not "ZLOG" - before someone more cranky comes in to correct you. ;) )
Block sizes: Both do the same thing, just
volblocksize is for ZVOLs and
recordsize is for datasets - they limit the maximum size of a record that ZFS will write (and you can't change
volblocksize on the fly!). The
LogicalBlockSize is what will be seen by the iSCSI initiator (related to the "physical block size supported by the device" link - I believe you need VMFS6 support to handle 4K.)
The decision on what volblocksize/recordsize to use is a balancing act - a larger block size reduces overhead for large file transfers and sequential transfers, but penalizes smaller, random I/O - the issue is made even worse if a disk image is created as a "thick" or fully allocated disk, which populates with the maximum recordsize (eg: 64K) but then the VM does a smaller write (NTFS defaults to 4K clusters, for example) - which results in every 4K write needing to read the entire 64K record, modify part of it, and then write it. Your second source on the 64K write actually calls out that 32K records worked a little better - but bandwidth is only part of the calculation, latency is also an important metric for VMs.
For database workloads, you actually want to align your ZFS recordsize against the database internal recordsize - eg: 8K or 16K - to avoid the partial record modification mentioned above.
Generally speaking, lower recordsize gives better latency - higher recordsize gives better bandwidth; and since running VM performance tends to be latency-dependent, the trending is towards lower sizes; but the smaller the recordsize, the more metadata is generated and the more sequential performance (eg: large copies, storage migrations) suffers.
Summary: Your current SSDs aren't fast enough to be good SLOG devices, so don't turn on
sync=always until you get better ones. Smaller records give lower latency, larger records give better bandwidth; the balance is yours to find, I personally like 16K.
Question: Is there a particular need to use iSCSI for the media storage (data-bronze) or can you switch to a file-based protocol like SMB/NFS?
