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?
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.
That was indeed one of the main drivers for it! ESP32 (especially with 2.4GHz WiFi latencies) is not super well suited for OS installs, but... many UEFI firmwares (and some network drivers!) will let you boot iSCSI directly.
The other one is the Raspberry Pi{3,4,5} iSCSI shim linked there as well - I have a bunch of them for a bunch of paying clients CI/CD kinds of work, and I wanted these to boot from network, not from microSD.
Both of these projects could've benefited from a public demo iSCSI endpoint, we have http://example.com and whateveryouwant@mailinator.com - why not iSCSI
Ah, yeah, drat. I forgot entirely about the moonshot that becomes streaming several GB through the ESP... I was just thinking of an easier solution that avoids UEFI networking - wireless devices, tablets, odd things like that ;)
Then again this might still be useful yet - a small 64MB thumb drive with an autounattend.xml streamed to it is also an equally powerful tool for some Windows shenanigans.
The Pi4 shim actually exposes USB device as well. This works way, way better (and IMHO mostly because wired network is better than wireless for latency, ESP32’s feeble CPU aside)
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.
Eh, the main thing you would feel with this is latency, not bandwidth. Even on a 10 Mbps LAN, you would be able to open a file pretty quick, but over the internet latency is going to be > 100 ms in almost every case. That's a lot more painful.
Correct. Well, almost correct. Will see how much uptake this service will take (if any), and we can probably place it really close to the edge - for now it's on an Oregon server only.
That said, this isn't too far from mechanical HDD latencies of the /real/ SCSI drives.
I've answered some down the tree a bit for the inspirational use case for it.
Since I built it, I've started seeing it as a hammer for many nail-like problems - I think that would die down over time;
but.. I have my ESP32 "pendrive" that's net-synced. I have used it to install OS through UEFI-built-in initiator. I have added iSCSI targets to my windows laptop machine (and VMs) - while you need to deal with disconnects and reconnects, it actually works well enough.
It is a terrible idea, that doesn't sound as terrible for odd use-cases. But yes, the ESP32 over 2.4GHz over 3G internet is slow as molasses (20-30kB/s) - but when the alternative is 0.. or walking over there with a laptop, it works OK.
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.