I thought I'd write up a few lines about the NetBSD iSCSI initiator
which I've committed to -current.  It's in the

	src/share/examples/refuse/iscsi-initiator

directory in the repository.

The NetBSD iSCSI initiator is different to the other initiators that
are out there - it is completely implemented in userland, and is
layered on top of ReFUSE and puffs. 


USAGE
=====

Firstly, a quick overview of how to use it:

(I have an iSCSI target running on the inspiron1300 machine,
IPv4 address 10.4.0.42, presenting a LUN that's 100 MB in size)

1. Firstly, as root, invoke the initiator, with a user name
to log in to the target, and a directory to use for the initiator:

	# obj/iscsifs -u agc inspiron1300 /mnt &
	inspiron1300.wherever.co.uk: 10.4.0.42:3260,1 iqn.1994-04.org.netbsd.iscsi-target:target0

The /mnt directory will grow a virtual directory hierarchy underneath
it to represent the target machine, and one underneath that to show
the target (aka LUN) that is being presented:

	# ls -al /mnt/inspiron1300.wherever.co.uk/target0
	total 576
	drwxr-xr-x  2 agc  agc        512 Nov  9 17:55 .
	drwxr-xr-x  2 agc  agc        512 Nov  9 17:55 ..
	lrw-r--r--  1 agc  agc         44 Nov  9 17:55 hostname -> inspiron1300.wherever.co.uk
	lrw-r--r--  1 agc  agc          9 Nov  9 17:55 ip -> 10.4.0.42
	lrw-r--r--  1 agc  agc         16 Nov  9 17:55 product -> NetBSD iSCSI    
	-rw-r--r--  1 agc  agc  104857088 Nov  9 17:55 storage
	lrw-r--r--  1 agc  agc         43 Nov  9 17:55 targetname -> iqn.1994-04.org.netbsd.iscsi-target:target0
	lrw-r--r--  1 agc  agc          8 Nov  9 17:55 vendor -> NetBSD  
	lrw-r--r--  1 agc  agc          4 Nov  9 17:55 version -> 0   
	#

Most of the virtual directory entries should be self-describing.
One important one to note there is the virtual regular file 
called "storage" - this is a representation of the storage
presented by the target.

2. Configure a vnd device so that the storage presented by the
target can be accessed using a device:

	# vnconfig vnd0 /mnt/inspiron1300.wherever.co.uk/target0/storage

3. A file sytsem can then be made and used just the same as
normal:

	# mount /dev/vnd0a /iscsi
	# disklabel -e /dev/vnd0a
	# newfs /dev/vnd0a
	/dev/vnd0a: 100.0MB (204798 sectors) block size 8192, fragment size 1024
		using 4 cylinder groups of 25.00MB, 3200 blks, 6208 inodes.
	super-block backups (for fsck_ffs -b #) at:
	32, 51232, 102432, 153632,
	# mount /dev/vnd0a /iscsi
	# df
	Filesystem   1K-blocks       Used      Avail %Cap Mounted on
	/dev/dk0      28101396   21493426    5202902  80% /
	kernfs               1          1          0 100% /kern
	procfs               4          4          0 100% /proc
	ptyfs                1          1          0 100% /dev/pts
	/dev/puffs           0          0          0 100% /mnt
	/dev/vnd0a       99214          1      94253   0% /iscsi
	#

Now, as far as stability goes, I have been very happily surprised. 
The first test for the initiator was when Greg Oster ran a build.sh to
build NetBSD userland and kernels.  Greg's results were not only that
the build completed successfully, but that the times for the build to
complete were within 0.5% of the same build using a disk for storage,
on the same machine.  Admittedly, this is on an amd64 with 8 GB RAM,
so cache effects apply.  I believe that these results are also superb,
though - many thanks to Greg for driving through the final development
of the initiator, and for running all the tests.


ANALYSIS
========

So what does all this mean?

1. NetBSD-current can now use iSCSI storage as both a client and a
server

2. The NetBSD iSCSI initiator should be portable to any operating
system that can use a version of FUSE or ReFUSE, since it is
entirely coded in userland. I'd love to hear of any experiences,
positive or negative, with other operating systems.

3. Efficiency and performance seem, at the moment, to be adequate.

4. File systems implemented in userland need not necessarily be
thought of as toys, or as inefficient, or non-performing. They
are much easier to debug.

5. Separate pass to userland device functionality is not needed,
since puffs can pass file sytsem requests onto a userland
program which can emulate or wrap the device. 


ROADMAP
=======

The decision to implement the initiator in userland may seem like
an unusual one, and its use of puffs and ReFUSE is certainly
novel. I believe that certain parts of the iSCSI initiator belong
in userland - authentication, and probably any aggregation - and I'd
like to see us develop a version of the initiator further, so that
initial setup, discovery and full login are done in userland, after
which the bulk of the work is done in the kernel, without the
intermediate puffs step.  Whilst this would limit portability, it
could also increase speed, if it's found that we're lacking in
performance.

Equally, the step to use a vnd device should be made redundant,
although, as shown earlier, it's relatively easy to use.

I have stopped working on pud - pass to userspace device functionality
- since I realised that it was unnecessary with puffs right now.  The
userland part of the file system that is implemented can take care of
emulating any device that is necessary.

It's also interesting to note that the same kind of thing could
be done for ppp, to take one example from the top of my head.

Moving forward, I'd like to put the initiator in /sbin, so it's
available fairly early on in the boot process. There may also
be room for adding iSCSI boot smarts (i.e. part of the initiator
functionality) to network drivers, to allow native iSCSI boot.
Please contact me if you're interested in this.

The NetBSD iSCSI target will also develop functionality to control it,
rather than having to make changes to a configuration file and then
restart the target.


SUMMARY
=======

Hopefully, all this explains where we're at with the NetBSD
iSCSI initiator right now, and also where we're going with it.
If anything is unclear, or if anything needs further explanation,
please don't hesitate to contact me.


Enjoy,
Alistair