block sizes for zvol and iscsi

[digity]

I'm setting up a Windows gaming VM where some games will be installed on a separate drive (D:). That D: drive will be a zvol served up via iSCSI from TrueNAS. The zvol is on a pool made up of 3 x mirrored vdevs. Network throughput is 40 Gb/s. I understand game loading times won't be as fast as if they were on a SSD drive or (SSD pool), but I'm hoping it's at least faster than a traditional physical gaming machine setup (i.e.,, where games are installed on a large single HDD). For this type of setup with game installations/files, what should the block size be set to when creating the zvol (4 KiB, 8 KiB, 16 KiB, 32 KiB, 64 KiB or 128 KiB) and what should the logical block size be set to for the iSCSI extent (512, 1024, 2048 or 4096)?

P.S. - The type of games that will be installed/played will be anything from from older/old school games to indie games to AAA games.

P.P.S. - the C: drive for the VM will be stored on a SSD pool in a standard dataset (i.e., ESXi datastore over NFS)

 

[morganL]

By default, 128K should be good for games.

Having a smaller block size is useful if there are a lot of small writes. I doubt that is the case, unless there's a specific game that does that. (Disclaimer: I'm not a gamer)

 

[HoneyBadger]

Most modern AAA games store their assets inside of large data files (and I doubt even a single texture file is under 128K these days) so using a large zvol recordsize is likely the best course of action. Even modern indie titles do the same with a Unity assetbundle or UE .pak file. Even during the updates/patches, you're likely to be overwriting large chunks of the file at a time, so I wouldn't expect much in the way of fragmentation.

The 128K is also a maximum, not a minimum, so if your retro titles are writing smaller files (although even the original DOOM has a multi-megabyte IWAD) than the recordsize (volblocksize) ZFS should have no issues writing them in smaller pieces as needed.

Your Logical Block Size should be either 512 or 4096 - this is what the guest OS will see as the "sector size" of the drive, and Windows will expect it to be one of those two.

What you also want to do is provision the zvol as a sparse volume, in order to allow your Windows guest OS to see it as a valid target for TRIM/UNMAP commands. This will let it reclaim space when files are deleted or updated through a patch, and hopefully keep the free space fragmentation down on your pool.

Leave compression on, but don't use deduplication.