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.
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.
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)
Hi HN - Tom here, I built scsipub.
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.
I saw the mention of BEAM in the article, and immediately wanted to know more. But I don't have any specific questions unfortunately...
This is the kind of post that makes me wish HN had bookmarks. The open-iscsi IQN slash issue alone was worth the read. Great work.
> This is the kind of post that makes me wish HN had bookmarks.
You could 'abuse' favorite for that. Works for whole threads, or just single comments.
Thanks! Let me know if you have any questions - I've long wanted to write something "system-level" in Elixir.
Click the "minutes ago" and then click on "favorite". Basic but it works.
I should reevaluate my feeling about iscsi I developed around the md1000 era.
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.