Hello!
I’d like to experiment with setting up an iSCSI target on a TrueNAS server to use as storage for a modern Mac OS production system.
Mac OS’ APFS file system fairly confusing when it comes to understanding how it works and how Mac OS uses it; I have no idea how to set the volblocksize.
What volbocksize should I use for the dataset where the iSCSI volume is going to live?
This is a workload question. What programs are the client using the volume for?
I’ll second that, but offer a generic rule of thumb–you generally want 64KiB blocks for general-purpose VM use, which is essentially what you’re doing here (in terms of how the storage is used).
In some specialized heavy-duty workloads you may want larger blocks (streaming servers) or smaller blocks (database engines) but if the answer is “uhh… you know, like, Mac, running desktop apps and stuff” then you want to start with 64K.
If you set up your first one and the 64K feels “laggy” to you, then you want smaller blocksizes. If it responds quickly (eg listing files, changing directories, pulling up file properties, etc) but doesn’t give you much high end speed when copying lots of very large files, that’s when you’d want to consider larger blocksizes.
Thank you both. @mercenary_sysadmin , I especially appreciate the advice on how to do trial-and-error tuning. A lot of online sources just tell you to tune for best performance without any practical details. 
For context, APFS is the default filesystem for modern MacOS disks, so it’s also the preferred filesystem for Time Machine and Carbon Copy Cloner backups. Both of those solutions can back up over SMB, but using SMB makes Time Machine act wonky and makes a lot of CCC’s features (like Snapshots) just not available at all.
So, I wanted to experiment with using iSCSI as a backup target for CCC. I talked to the CCC dev, and apparently the (small pool) of users who’ve used iSCSI have had good results with it. (I also have a cloud backup service, so I’m not gambling with my only backup.)
After my OP here, I also found this article: APFS: Containers and volumes – The Eclectic Light Company
Currently, each APFS container can have as many as 100 file systems (volumes) within it, although in practice space requirements may impose a lower figure. To calculate the maximum number of file systems for any container, divide the container size by 512 MiB and round up to the nearest integer. For example, a container of size 10 GiB can contain a maximum of 20 volumes. The smallest permitted container has a size of 1,048,576 bytes. Storage block size is fixed at a minimum of 4096 bytes, which is also set as the default, and a maximum of 65536 bytes.
I need to confirm, but I assume Mac OS uses the default 64k blocksize, as the file system was created for Mac OS. 
So, that works out nicely.
TrueNAS provides a TimeMachine-specific SMB Share type where macOS creates a virtual APFS disk which has all the APFS features including snapshots. I’ve been doing that for a number of months without any issue. No need for an iSCSI initiator.
Thanks!
I’ll do this for my Time Machine backups. Thanks! Assuming TimeMachine backs up every hour, how often do you run ZFS snapshots on the dataset?
I’d still like to learn how to use iSCSI, and having an iSCSI APFS disk would still be useful. Of course, my biggest blocker on experimenting with this is having to figure out what initiator to use.
I don’t snapshot them. Thought about it and I might do it someday but today is not that day.
I might not have given enough thought to a failure of the virtual volume or a ransomware attack but pretty much all the data is protected in depth elsewhere and my TM backups are more for AA easy complete system restore
I think the article I was reading was concerned about the Time Machine backup itself becoming corrupted via Time Machine experiencing some sort of error.
I agree, though: I have two other backups set up for this machine, aside from almost all my critical files being in cloud storage, anyway. I like having Time Machine as a convenient versioning system and system restore–which I’ve thankfully never had to do.
This is a pretty reasonable concern, and I’d recommend at least a week’s worth of daily snapshots to guard against it. Shouldn’t really cost you all that much, and you might wind up INCREDIBLY glad for it at some point if things go badly wrong.
BTW, the key factor with Time Machine over SMB is that you need a new version of the SMB protocol. You may have simply been using a too-old version of Samba to support the newer versions of TM; it got overhauled significantly with, IIRC, Big Sur and as a result lost support for older SMB versions.