Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/dist/iscsi Import the distribution files for the iSCSI targe...
details: https://anonhg.NetBSD.org/src/rev/57a62d60c826
branches: trunk
changeset: 588119:57a62d60c826
user: agc <agc%NetBSD.org@localhost>
date: Wed Feb 08 18:56:14 2006 +0000
description:
Import the distribution files for the iSCSI target, developed from the
original Intel code (BSD-licensed) in othersrc, by myself.
This provides an iSCSI target implementation in userland, as well as a
test harness which also runs in userland.
The iSCSI target has been tested with version 1.06 of the Microsoft
initiator, as well as with its own test harness.
diffstat:
dist/iscsi/doc/FAQ | 198 +
dist/iscsi/doc/PERFORMANCE | 64 +
dist/iscsi/doc/README | 188 +
dist/iscsi/doc/README_OSD | 58 +
dist/iscsi/doc/license | 31 +
dist/iscsi/doc/messages.1 | 1720 +++++++++++
dist/iscsi/include/compat.h | 22 +
dist/iscsi/include/conffile.h | 76 +
dist/iscsi/include/config.h | 140 +
dist/iscsi/include/config.h.in | 154 +
dist/iscsi/include/defs.h | 99 +
dist/iscsi/include/device.h | 52 +
dist/iscsi/include/driver.h | 157 +
dist/iscsi/include/initiator.h | 126 +
dist/iscsi/include/iscsi.h | 518 +++
dist/iscsi/include/md5.h | 54 +
dist/iscsi/include/osd.h | 145 +
dist/iscsi/include/osd_ops.h | 61 +
dist/iscsi/include/parameters.h | 176 +
dist/iscsi/include/scsi_cmd_codes.h | 25 +
dist/iscsi/include/so.h | 56 +
dist/iscsi/include/storage.h | 86 +
dist/iscsi/include/target.h | 100 +
dist/iscsi/include/tests.h | 50 +
dist/iscsi/include/util.h | 609 ++++
dist/iscsi/src/Makefile.in | 160 +
dist/iscsi/src/TODO | 31 +
dist/iscsi/src/auths | 16 +
dist/iscsi/src/conffile.c | 281 +
dist/iscsi/src/configure | 5052 ++++++++++++++++++++++++++++++++++
dist/iscsi/src/configure.ac | 26 +
dist/iscsi/src/disk.c | 1157 +++++++
dist/iscsi/src/driver.c | 652 ++++
dist/iscsi/src/etc/auths | 17 +
dist/iscsi/src/etc/passwd | 12 +
dist/iscsi/src/etc/rc.d/iscsi_target | 18 +
dist/iscsi/src/etc/targets | 21 +
dist/iscsi/src/examples/1.conf | 20 +
dist/iscsi/src/examples/2.conf | 19 +
dist/iscsi/src/examples/3.conf | 22 +
dist/iscsi/src/examples/4.conf | 23 +
dist/iscsi/src/initiator.c | 3187 +++++++++++++++++++++
dist/iscsi/src/install-sh | 238 +
dist/iscsi/src/iscsi-harness.8 | 92 +
dist/iscsi/src/iscsi-harness.c | 192 +
dist/iscsi/src/iscsi-target.8 | 111 +
dist/iscsi/src/iscsi-target.c | 475 +++
dist/iscsi/src/iscsi.c | 1342 +++++++++
dist/iscsi/src/ktarget.c | 76 +
dist/iscsi/src/ktest.c | 59 +
dist/iscsi/src/lint.mk | 10 +
dist/iscsi/src/md5.c | 241 +
dist/iscsi/src/mknodes.c | 24 +
dist/iscsi/src/mount_iscsi.c | 288 +
dist/iscsi/src/osd-target.c | 149 +
dist/iscsi/src/osd.c | 662 ++++
dist/iscsi/src/osd_ops.c | 410 ++
dist/iscsi/src/osdfs.c | 1076 +++++++
dist/iscsi/src/parameters.c | 1276 ++++++++
dist/iscsi/src/snprintf.c | 665 ++++
dist/iscsi/src/so.c | 1060 +++++++
dist/iscsi/src/start_osd | 5 +
dist/iscsi/src/stop_osd | 5 +
dist/iscsi/src/strlcpy.c | 88 +
dist/iscsi/src/strtoll.c | 70 +
dist/iscsi/src/target.c | 1584 ++++++++++
dist/iscsi/src/targets | 20 +
dist/iscsi/src/targets.5 | 148 +
dist/iscsi/src/tests.c | 1336 ++++++++
dist/iscsi/src/usocktest.c | 378 ++
dist/iscsi/src/utest.c | 158 +
dist/iscsi/src/util.c | 1011 ++++++
72 files changed, 28928 insertions(+), 0 deletions(-)
diffs (truncated from 29216 to 300 lines):
diff -r b0b66c683f38 -r 57a62d60c826 dist/iscsi/doc/FAQ
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dist/iscsi/doc/FAQ Wed Feb 08 18:56:14 2006 +0000
@@ -0,0 +1,198 @@
+iSCSI Frequently Asked Questions
+================================
+
+Q1. What is iSCSI?
+==================
+
+A1. It's an IETF standard (RFC 3720) for remote access to block-level
+storage. It can be thought of as similar to NFS, except that an NFS
+server exports files, which the iSCSI target exports blocks to the
+iSCSI initiators, which are the clients.
+
+
+Q2. What's the difference between an initiator and a target?
+============================================================
+
+A2. The target is the iSCSI server - it serves up blocks to the
+clients, which are called initiators. Typically, initiators are part
+of the operating system, since the operating system manages block
+storage, presenting it to the user as file systems sitting on top of
+the storage.
+
+Targets do not generally need to be part of the operating system,
+indeed there is some flexibility to be gained by having targets as
+part of the user-level daemons that are run. This means that
+security credentials need not be buried in the kernel.
+
+
+Q3. So how do I use it?
+=======================
+
+A3. Firstly, you need to set up the iSCSI target. The target is
+simply sitting there, waiting for requests for blocks. So we need to
+configure the target with an area of storage for it to present to the
+initiators.
+
+To set up the target, you need to edit the /etc/iscsi/targets file.
+It has a certain layout, to provide a means of (a) mirroring and (b)
+combining multiple areas to present one large contiguous area of
+storage. This can be multiply-layered.
+
+The basic unit of storage is an extent. This can be either a file
+or a device. The offset of the start of the extent to be presented
+must be given, and also the length of the extent.
+
+A device is made up of one or more extents, and/or one or more
+other devices.
+
+At the highest level, a target is what is presented to the initiator,
+and is made up of one or more devices, and/or one or more extents.
+
+The simple example is as follows, consisting of one piece of storage
+presented by one target:
+
+ # extent file or device start length
+ extent0 /tmp/iscsi-target0 0 100MB
+
+will produce an extent of storage which is based on one file,
+/tmp/iscsi-target0, which starts 0 bytes into the file, and is 100 MB
+in length. The file will be created if it does not already exist.
+
+ # target storage netmask
+ target0 extent0 0.0.0.0/0
+
+That extent is then used in target0, and will be presented to an
+initiator running on any host.
+
+Extents must be defined before they can be used, and extents cannot
+be used more than once.
+
+Devices are used to combine extents or other devices. Device
+definitions have the following format:
+
+ # devices
+ device0 RAID1 extent0 extent1
+
+A "RAID1" device behaves in much the same way that RAID1 devices work
+in the storage arena - they mirror the original storage. There can be
+any number of devices or extents in a RAID1 device, not just 2, but
+each device or extent must be of the same size.
+
+A "RAID0" device combines the storage, to produce a larger area of
+(virtually) "contiguous" storage.
+
+Devices must be defined before they can be used, and devices may not
+be used more than once.
+
+A more detailed example would be as follows:
+
+ # Complex file showing 3-way RAID1 (with RAID1 components),
+ # also using local and (NFS) remote components
+
+ # extents
+ extent0 /iscsi/extents/0 0 100MB
+ extent1 /imports/remote1/iscsi/extents/0 0 100MB
+ extent2 /iscsi/extents/1 0 100MB
+ extent3 /imports/remote1/iscsi/extents/1 0 100MB
+ extent4 /iscsi/extents/2 0 100MB
+ extent5 /imports/remote1/iscsi/extents/2 0 100MB
+ extent6 /iscsi/extents/3 0 100GB
+
+ # devices
+ device0 RAID1 extent0 extent1
+ device1 RAID1 extent2 extent3
+ device2 RAID1 extent4 extent5
+ device3 RAID1 device0 device1 device2
+
+ # targets
+ target0 device3 10.4.0.0/16
+
+ # a target can be made from just an extent
+ target1 extent6 127.0.0.0/8
+
+which will make 7 extents, 3 of them 100 MB in length and remote (via
+NFS), and 3 of them 100 MB in length and local, and one of them large
+(100 GB) and local. Three separate occurrences of a local and remote
+100 MB extent are combined to make three RAID1 devices, and then those
+three RAID1 devices are combined into another RAID1 device, and
+presented as target0.
+
+The other extent is used to present a simple 100 GB of storage as
+target1.
+
+
+Q4. What about security?
+=========================
+
+A4. A good question. RFC 3720 specifies CHAP, SRM and Kerberos as
+methods of providing authentication and/or security. In practice,
+it's whatever is provided by the initiator you are using which will
+determine what authentication or security is used.
+
+In practice, it's probably best to use ssh port forwarding for all
+your traffic if you're worried about security. CHAP will only provide
+authentication, the other information will flow across the network in
+clear.
+
+
+Q5. Using the Microsoft initiator, I can't login with CHAP
+===========================================================
+
+A5. The 1.06 Microsoft initiator silently enforces a chap password
+length of at least 12 characters. If you enter a password which is
+less than that, your Discovery login will silently fail.
+
+Since CHAP provides very little authentication anyway, you are advised
+not to use it - ssh port forwarding, and the use of tcp wrappers,
+will do a much better job of protection anyway.
+
+
+Q6. What initiators work with the NetBSD iSCSI target?
+======================================================
+
+A6. The NetBSD target has been tested at various times with the Microsoft
+iSCSI initiator, version 1.06 (which can be downloaded for free from
+www.microsoft.com, but needs Windows XP Pro to work), and also with the
+NetBSD test harness, which is provided, but not installed, in the same
+place as the target.
+
+
+Q7. What is the difference between Discovery and Normal login?
+===============================================================
+
+A7. On direct-attached storage, the kernel verifies what storage is
+available, and assigns a device node to it. With iSCSI, storage can
+come and go, and our proximity to the devices doesn't matter. So we
+need to find a different method of finding out what iSCSI storage is
+out there.
+
+This is done by a "Discovery" iSCSI session - the initiator logs in
+to the target, finds out what storage is being presented, then logs
+back out. This can be seen by the syslog entries:
+
+ Feb 5 10:33:44 sys3 iscsi-target: > Discovery login from iqn.1991-05.com.microsoft:inspiron on 10.4.1.5
+ Feb 5 10:33:44 sys3 iscsi-target: < Discovery logout from iqn.1991-05.com.microsoft:inspiron on 10.4.1.5
+
+The initiator will then perform a "Normal" login session, which will
+establish a session between the initiator and target. This is denoted
+by the syslog entries:
+
+ Feb 5 00:00:28 sys3 iscsi-target: > Discovery login from iqn.1993-03.org.NetBSD.iscsi-initiator:agc on 127.0.0.1
+ Feb 5 00:00:28 sys3 iscsi-target: < Discovery logout from iqn.1993-03.org.NetBSD.iscsi-initiator:agc on 127.0.0.1
+ Feb 5 00:00:28 sys3 iscsi-target: > Normal login from iqn.1993-03.org.NetBSD.iscsi-initiator:agc on 127.0.0.1
+ Feb 5 00:05:32 sys3 iscsi-target: < Normal logout from iqn.1993-03.org.NetBSD.iscsi-initiator:agc on 127.0.0.1
+
+
+Q8. So what do I do to try it?
+==============================
+
+A8. Perform the following steps:
+
+a) define the storage that you want to present in /etc/iscsi/targets
+b) start the iSCSI target: /etc/rc.d/iscsi_target forcestart
+c) use an initiator to point it at the machine you started it on
+
+
+Alistair Crooks
+agc%NetBSD.org@localhost
+Wed Feb 8 07:21:56 GMT 2006
diff -r b0b66c683f38 -r 57a62d60c826 dist/iscsi/doc/PERFORMANCE
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dist/iscsi/doc/PERFORMANCE Wed Feb 08 18:56:14 2006 +0000
@@ -0,0 +1,64 @@
+
+----------------------
+USER LEVEL PERFORMANCE
+----------------------
+
+If your system is correctly configured with GbE and a GHz processor,
+you should expect user level iSCSI performance similar to the following.
+This output was generated by running utest against a target running uramdisk.
+
+##BEGIN DEVICE-SPECIFIC TESTS[0:0]##
+read_capacity PASSED
+write_read_test PASSED
+integrity_test PASSED
+SCSI op 0x28: 1000 iters in 0.24 sec --> 244.38 usec
+SCSI op 0x2a: 1000 iters in 0.25 sec --> 249.78 usec
+SCSI op 0x25: 1000 iters in 0.25 sec --> 250.12 usec
+8192 bytes/request: 8 MB written in 0.33 seconds --> 24.35 MB/sec
+16384 bytes/request: 8 MB written in 0.30 seconds --> 26.74 MB/sec
+32768 bytes/request: 8 MB written in 0.20 seconds --> 39.06 MB/sec
+65536 bytes/request: 8 MB written in 0.15 seconds --> 52.95 MB/sec
+131072 bytes/request: 8 MB written in 0.12 seconds --> 66.74 MB/sec
+262144 bytes/request: 8 MB written in 0.10 seconds --> 77.76 MB/sec
+8192 bytes/request: 8 MB read in 0.37 seconds --> 21.34 MB/sec
+16384 bytes/request: 8 MB read in 0.19 seconds --> 41.47 MB/sec
+32768 bytes/request: 8 MB read in 0.13 seconds --> 62.04 MB/sec
+65536 bytes/request: 8 MB read in 0.11 seconds --> 70.99 MB/sec
+131072 bytes/request: 8 MB read in 0.10 seconds --> 83.62 MB/sec
+262144 bytes/request: 8 MB read in 0.09 seconds --> 92.38 MB/sec
+##END DEVICE-SPECIFIC TESTS[0:0]##
+
+------------------------
+KERNEL LEVEL PERFORMANCE
+------------------------
+
+Kernel level performance (ktest to kramdisk.o) should be similar to the output
+shown below. Note that this test does not go through the linux storage stack,
+but is rather a kernel level iSCSI test with no attached filesystem or SCSI
+midlayer.
+
+This output was generated by installing the module intel_iscsi.o and then
+running "ktest <device>" where <device> is one of your iscsi devices (e.g,
+/dev/sdb). Although you specify a single device on the command line, all
+target devices are tested.
+
+##BEGIN DEVICE-SPECIFIC TESTS[0:0]##
+read_capacity PASSED
+write_read_test PASSED
+integrity_test PASSED
+SCSI op 0x28: 1000 iters in 25 jiffies --> 250 usec
+SCSI op 0x2a: 1000 iters in 25 jiffies --> 250 usec
+SCSI op 0x25: 1000 iters in 25 jiffies --> 250 usec
+8192 bytes/request: 8388608 bytes written in 38 jiffies --> ~ 21 MB/second
+16384 bytes/request: 8388608 bytes written in 38 jiffies --> ~ 21 MB/second
+32768 bytes/request: 8388608 bytes written in 23 jiffies --> ~ 34 MB/second
+65536 bytes/request: 8388608 bytes written in 16 jiffies --> ~ 50 MB/second
+131072 bytes/request: 8388608 bytes written in 12 jiffies --> ~ 66 MB/second
+262144 bytes/request: 8388608 bytes written in 10 jiffies --> ~ 79 MB/second
+8192 bytes/request: 8388608 bytes read in 26 jiffies --> ~ 30 MB/second
+16384 bytes/request: 8388608 bytes read in 20 jiffies --> ~ 39 MB/second
+32768 bytes/request: 8388608 bytes read in 12 jiffies --> ~ 66 MB/second
+65536 bytes/request: 8388608 bytes read in 12 jiffies --> ~ 66 MB/second
+131072 bytes/request: 8388608 bytes read in 10 jiffies --> ~ 79 MB/second
+262144 bytes/request: 8388608 bytes read in 9 jiffies --> ~ 88 MB/second
+##END DEVICE-SPECIFIC TESTS[0:0]##
diff -r b0b66c683f38 -r 57a62d60c826 dist/iscsi/doc/README
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dist/iscsi/doc/README Wed Feb 08 18:56:14 2006 +0000
@@ -0,0 +1,188 @@
+
+---------------------------------------
+Intel iSCSI v20 Reference Implementation
+---------------------------------------
+
+This is a software implementation of iSCSI v20. Included in this distribution
+are both host and target mode drivers with built in conformance and performance
+tests, and sockets tests that can be used to simulate TCP traffic identical to
+that generated between a real iSCSI host and target.
+
+See PERFORMANCE for information regarding the expected performance of this
+distribution.
+
+This code has been successfully compiled and tested on Redhat 8.0
+(kernel version 2.4.18-14) and Redhat 9.0 (kernel version 2.4.20)
+with UP and SMP configurations.
+
+-------------------
+Starting the System
+-------------------
+
+1a) Modify the array in initiator.c to contain your target ip addresses and port
+ numbers. If you specify a TargetName there will be no discovery process. For
+ example, targets 0 and 2 below will first be discovered. Target 1 will not.
+ ISCSI_PORT is the default port defined in iscsi.h and currently set to 3260.
+
Home |
Main Index |
Thread Index |
Old Index