[Openib-windows] File transfer performance options

[Paul Baxter]

> IB/SRP is block level storage like iSCSI and FC. A storage system can 
> export multiple volumes.
> However, every exported volume can only be exclusively used by an 
> initiator (server accessing the storage) unless you use a cluster file 
> system.
>
> If you need to access the same volume from multiple initiators at the same 
> time SRP is not an option. NFS o IB would be – but there are no Windows 
> clients available.


My distributed Linux app reads multiple channels of sensor data at high 
speed in real time to local disks and at a convenient break switches from 
'record' to 'archive' to allow a remote Windows archiver to remotely read 
recently recorded data and write to a much bigger Windows-based store.

I think I may be describing things using the wrong terminology.

Looking at this from the archiver point of view, I have a single 
windows-based application that is required to read from several quite 
separate Linux (RAID-based) volumes. Each volume is hosted within a separate 
Linux-based node.

Can I have one windows-based SRP-initiator (or perhaps several instances of 
this on one windows node).

One instance of an initiator deals exclusively with one Linux-based SRP 
client on one separate Linux node.
[If multiple initiators are not possible, I can sequentially 'drain' each 
Linux disk and then close the SRP initiator and start a new one accessing a 
new Linux node (??)]

The Linux nodes are 'serving' their data at the initiation of a 
windows-based client. (terminology?)

I also appreciate that while Windows is remotely accessing a disk, the Linux 
machine must keep its hands off its local disk.

My Linux application does actually talk with the windows application to 
ensure exclusivity, I just didn't want my Linux app or the equivalent 
Windows side to actually have to transfer files via messages if remote file 
transfer semantics between drivers was sufficient.

I'm hoping someone can now tell me that yes, SRP can do this today (or at a 
pinch tomorrow).

Thanks for any further hints.

Paul Baxter