Using ZFS as an iSCSI Target for Mac OS: Volbocksize and Recordsize?

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?

2 Likes

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.

1 Like

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. :slight_smile:

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. :stuck_out_tongue: So, that works out nicely. :slight_smile:

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.

1 Like

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.

1 Like

Thanks for the recommendation for the snapshot schedule.

I never did follow up on this; I apologize. I didn’t get to test using iSCSI with Time Machine (or on the Mac at all), because the Mac doesn’t ship with a native iSCSI initiator in the OS.

There’s a free one that’s limited to like 20 MB/s or some other sub-100 MB/s speed that makes it completely not worth it vs. SMB/NFS, and paid tool that costs $195. That’s a bit much to justify just to experiment, unless I trip over a leprechaun or something. :wink:

I just took a peek, and I see what you mean. There used to be lots of iSCSI initiators for macOS, even several FOSS ones. But Apple took away third-party access to the system sockets necessary, which killed off all of the free and most of the proprietary iSCSI tools overnight with no way to fix it.

Apple. Ugh.

Yeah. It’d be a different story if they actually included a native iSCSI initiator. They include client/server implementations for SMB and NFS.

They used to include one as part of the Mac OS X Server (and later, Server Tools for normal MacOS X), but that’s been dead for years.

Grabbing a modern iSCSI implantation from BSD or Linux wouldn’t be trivial, but it’s hardly impossible, either.

For YEARS and years, Apple refused to allow OpenVPN (or any other third party VPN client) on iOS, because “it already has native VPN functionality.”

Except that “native VPN functionality” only worked with an UNSPECIFIED SUBSET of higher-end Cisco routers. Basically anything you found in a government office or large university with a Cisco nameplate on it, almost nothing you’d find in a small business office, but–again–THEY DIDN’T PUBLISH A COMPATIBILITY LIST so you just had to be like “lol idk, I guess you can’t haz” when a client wanted VPN functionality on their iPhone.

I grew up on Apple ][ machines, and the Woz is a personal hero. But I low-key kinda hope Steve Jobs is burning wherever he ended up. That dude sucked.

This is painful to read. I’ve had this idea to try an old Mac Mini as a “better *nix desktop” but it sounds like Apple has gimped most of the *nix from Darwin. :cry:

Does there exist converged network adapters with hardware iSCSI offload and full OS-independence (i.e. initiator lives entirely within NIC firmware, is configured entirely via UEFI HII, and presents as a disk device)?

Is Fibre Channel supported?