I wish there was built in iSCSI initiator support on macOS. All of the halfway decent third-party ones either broke many OS versions ago (GlobalSAN) or cost a small fortune ($250 for Atto Xtend)
The short version: it's iSCSI targets on the public internet. Pick
an image, get a block device. The free tier doesn't need a signup
at all - iscsiadm -m discovery -t sendtargets -p scsipub.com and
--login to iqn.2025-01.pub.scsipub:blank lands you a 64 MB
scratch disk. There's a small catalog of OS images you can mount
the same way.
The paid tier is where it gets less hobby-shaped: sessions survive
disconnects, a single target can expose multiple LUNs, and SCSI-3
Persistent Reservations work end-to-end (REGISTER / RESERVE /
RELEASE round-trip clean against sg_persist). That last bit is
the cluster-storage primitive — Pacemaker, ESXi HA, and Windows
MSCS all use PR for fencing — so you can actually back a 2-node
failover cluster off a target on the public internet.
The post linked in the submission is the architectural decision
log: Ranch 2.x listeners, a BEAM process per session, COW overlays
with per-sector bitmaps, Caddy-managed Let's Encrypt for the
iSCSI-TLS port without restarting the listener, and the four
open-iscsi quirks that each cost me few hours. There's a section on
what we're deliberately not solving (multi-region, RDMA, etc.)
so you know the scope.
Two companion projects ship as embedded sub-sites on the front
page — one turns an ESP32-S3 into a wireless iSCSI-to-USB bridge,
one lets a Raspberry Pi 3/4/5 netboot directly from a target. Both
linked from the landing page under "Hardware initiators".
Happy to answer any questions about the protocol, the deployment,
or the BEAM-side design choices.
I dislike neg comments but really curious - I can see the how but absolutely clueless about the why. Running a block device over a high latency WAN link seems like a terrible idea, what's the use case?
I don’t have a use case, but I was thinking the same thing. But then I realized that the WAN speeds available now are equal to or faster than the LAN speeds I had when I had reason to use iSCSI. And things worked out decently well then, so I can see this being useful.
Apparently, exposing small USB sticks to industrial equipment that uses it for loading/saving configs and screenshots and being able to 'network' it with shared iSCSI drives.
"The scope writes screen_001.png to “USB”; the file appears in a directory on my desktop, in the iSCSI overlay. Combined with a dropbox-style sync I no longer need to walk over and pull the stick out."
Quite brilliant and clever, if you ask me.
I'm wondering now about using an ESP32 stick and an iSCSI image of Windows install media - that could make for some fun in-house computer imaging setups.
If my experience with the MD1000 was like yours you developed the feeling for good reason. It has gotten better but I'll still take fibre channel over iSCSI every day.
The short version: it's iSCSI targets on the public internet. Pick an image, get a block device. The free tier doesn't need a signup at all - iscsiadm -m discovery -t sendtargets -p scsipub.com and --login to iqn.2025-01.pub.scsipub:blank lands you a 64 MB scratch disk. There's a small catalog of OS images you can mount the same way.
The paid tier is where it gets less hobby-shaped: sessions survive disconnects, a single target can expose multiple LUNs, and SCSI-3 Persistent Reservations work end-to-end (REGISTER / RESERVE / RELEASE round-trip clean against sg_persist). That last bit is the cluster-storage primitive — Pacemaker, ESXi HA, and Windows MSCS all use PR for fencing — so you can actually back a 2-node failover cluster off a target on the public internet.
The post linked in the submission is the architectural decision log: Ranch 2.x listeners, a BEAM process per session, COW overlays with per-sector bitmaps, Caddy-managed Let's Encrypt for the iSCSI-TLS port without restarting the listener, and the four open-iscsi quirks that each cost me few hours. There's a section on what we're deliberately not solving (multi-region, RDMA, etc.) so you know the scope.
Two companion projects ship as embedded sub-sites on the front page — one turns an ESP32-S3 into a wireless iSCSI-to-USB bridge, one lets a Raspberry Pi 3/4/5 netboot directly from a target. Both linked from the landing page under "Hardware initiators".
Happy to answer any questions about the protocol, the deployment, or the BEAM-side design choices.
Apparently, exposing small USB sticks to industrial equipment that uses it for loading/saving configs and screenshots and being able to 'network' it with shared iSCSI drives.
"The scope writes screen_001.png to “USB”; the file appears in a directory on my desktop, in the iSCSI overlay. Combined with a dropbox-style sync I no longer need to walk over and pull the stick out."
Quite brilliant and clever, if you ask me.
I'm wondering now about using an ESP32 stick and an iSCSI image of Windows install media - that could make for some fun in-house computer imaging setups.
You could 'abuse' favorite for that. Works for whole threads, or just single comments.