Initial commit

README

@@ -0,0 +1,58 @@
+go-iscsi
+********
+
+This project is a (c)go iscsi library, with the eventual aim of implementing a
+"hydra" iSCSI implementation.
+
+An hydra is an iSCSI target that, internally, takes requests and mirrors them
+across multiple *real* iSCSI targets, with the aim of ensuring redundancy and
+fault tolerance. The hydra (or Very Clever Proxy, as we could also call it) is
+intended to be run on the same host as the iSCSI initiator (qemu, say) to
+insulate the guest against the vagaries of disc failures, targets going away for
+any reason, etc, etc.
+
+This is being created specifically with redundant, fault-tolerant remote virtual
+discs in mind, so performance and reliability are key. Looks like this:
+
+TODO:
+
+  * Minimal iSCSI target implementation
+    - This should contain as few features as we can get away with, and is what
+       qemu will connect to - ideally over localhost (iscsi doesn't seem to
+       support UNIX sockets or I'd use those)
+  * Complete iSCSI initiator implementation
+    - This needs to support as much of iSCSI as possible, and certainly 
+      everything both QEMU and common real targets support
+    - Bindings to libiscsi are the way forward here
+  * Very Clever Proxy
+    - Takes a list of targets to keep in sync
+    - Runs the minimal target implementation
+    - Runs initiators for each of the real targets
+    - Proxies requests between local and remote targers, maintaining consistency
+    - Allows real targets to be swapped out for blanks that are then initialised
+      from the remaining targets
+    - One broken real target doesn't stall I/O for the real initiator
+    - Metadata is stored in reserved space on the real targets, and used to
+      ensure consistency if the Very Clever Proxy is killed at any stage and
+      brought back up on a different machine
+    - If a real target disconnects and then reconnects within a given window, it
+      can be brought back to consistency without reinitialising the whole disc
+    - Resizing is supported
+      + On resize down, the resize is propagated to the real initiator as soon
+        as the first real target has announced its new size
+      + On resize up, the resize is only propagated once all real targets have
+        announced a new size, and the propagated size is the smallest size they
+        all have in common
+    - The real initiator can submit requests asynchronously and have them dealt
+      with asynchronously
+    - Writes to the real targets happen concurrently, not serially, to avoid
+      multiplying write latency by the number of real targets
+    - Must be able to bind to a specific IP[4|6] address to enable IP-based ACLs
+    - Zero-copy, or as close to it as possible.
+    - Hides the first 1MiB of each real target for metadata to support the above
+      + Hiding the end would be problematic on resizes
+      + 1MiB is a complete crapshoot, 4KiB might be enough. Check.
+    
+DONE:
+
+