Views
  |
- ) Is the open source mobile revolution coming?
It appears to be shaping up that way. Please see: OpenMoko & FIC Neo1973?
- ) Why is this important from the IP storage perspective?
Having a open method to access GSM radio hardware will allow a device to access unlimited amounts of block level storage across the Internet Small Computer Systems Interface Protocol.
- ) Are IP storage services on mobile hardware platforms even possible?
Yes, have a look at the status of Rokr_E2 running Linux on Intel ARM/Xscale PXA microprocessors over GPRS and USB network links.
- ) What are the main limiting factors that exist for obtaining iSCSI on my mobile for my own storage resources wherever my travels take me with GSM infrastructure?
Client side:
GPRS Bandwith availability and cost, system memory for various forms of caching, and RO/RW filesystem considerations on your mobile.
Server side:
A working iSCSI Target with blocks containing a filesystem that the mobile can understand.
- ) What about my mobile's existing applications?!
iSCSI storage resources appear to your mobile's applications transparently. This is one of the primary benefits of traditional SAN architecture.
- ) What about new applications for my mobile?
Being able to both save and retrieve content including video, audio, images, block and filesystem level bits from remote storage resources. Most of these are limited by known network link limitations, cost of service, cost of hardware, and hardware availability. But make no mistake, iSCSI/GSM allows vendors to take existing mobile hardware and apply software updates to exceed the hardware's physical storage limitiations. Taking advantage of both iSCSI and iSNS software components in a manner that brings value to software offerings on open hardware platforms is the end result.
- ) What is the status of iSCSI/GSM?
The first iSCSI/TCP packets have been successfully transmitted over GPRS via tri-band GSM on a Motorola Rokr_E2 using MC/S and ERL=2 with a v2.4 kernel. Information related to iSCSI on quad-band GSM phones using Linux v2.6 that are shipping in 2007 will be posted here as they unfold.
- ) I thought that a iSCSI Initiator stack was too large / CPU intensive for such a underpowered device as a cell phone?
This is simply not true. A software iSCSI initiator stack can run on a ~70 Mhz ARM9 and easily max out even ideal GSM bandwith with single-digit CPU load using single threaded benchmark tools
- ) I thought that iSCSI was too 'heavy duty' a protocol for my mobile?
The question really becomes how useable is this type of infastructure on a communication network that runs at ISDN (~10 Kb) speeds. For accessing a large audio library, you just may with the right pieces of software and tuning, be able to have those terabytes of songs in your pocket usable by existing media players.
- ) How does iSCSI allow me to access storage resources on my cell phone?
Once your mobile (if supported) reaches 802.11 infrastructure, another communication path can be automatically opened for each connected iSCSI target node to take advantage of the bandwith while you are within reach of the APs. Once you are no longer within range of the APs, the communication path fails waiting for 802.11 PHY to come back online. At this point iSCSI traffic can resume flowing across the GSM communication path without need of breaking nexus between the multiple IP storage target nodes and your mobile.
- ) I don't know what Linux or iSCSI is, I just want to load network playlists from my PS3 WII XBOX360!?
The important piece from the application's perspective using said iSCSI storage is that this happens completely transparent to the SCSI subsystem and layers further up the operating system's storage stack. This is why internexus connection recovery with iSCSI is so important in networks where multiple communication paths exist and are expected to fail and recover on a regular basis. (See below)
- ) Why can't I just use NFS on my cell phone?
Lack of support for multiple communication paths and active-active recovery on communication path failure for starters. (see below) Also the lack of world wide unique naming (WWN) and discovery infrastructure does not help when it comes to scaling towards millions of nodes.
- ) What about dealing with data coherency and cluster filesystems?
Cluster filesystems across ISDN speeds is pretty undoable, after all these filesystems are typically designed for database loads with transports on the order of multiple Gb/sec datarates. A good piece of research for this problem would be how much iSCSI traffic is generated using R/O mounts using existing cluster filesystems in Linux v2.6. .
- ) Can I run multiple connections per session MC/S across both GSM and 802.11[g/b] infrastructure?
Yes, this would be ideal so that when you enter a hotspot the additional iSCSI connection comes up with the wireless PHY. Having connection recovery ERL=2 in use would be crucial here as the device moves from access point to access point as well as gracefully handling typical GSM communication failures that cause TCP connections to reset.