Showing posts with label iscsi. Show all posts
Showing posts with label iscsi. Show all posts

Wednesday, July 29, 2009

OpenSolaris 2009-06 and the Comstar iScsi Target

Having upgraded from OpenSolaris 2008-11 to 2009-06, I wanted to try the new Comstar iscsi target, to see how well it worked, and to see if it was ready to replace the 'old' iscsi target. And I wanted to see how far I could get with the package versions in the 'production-quality' release repository, based on snv_111. To start with, I just wanted to get something basic going as quickly as possible.

The first tasks was to disable the old iscsi target (to avoid a conflict with the new target which would also want to listen on TCP port 3260), and to enable the 'SCSI Target Mode Framework' - stmf.

# svcs iscsitgt
online Jul_09 svc:/system/iscsitgt:default
# svcs stmf
disabled Jul_09 svc:/system/stmf:default
# svcadm disable iscsitgt
# svcs iscsitgt
STATE STIME FMRI
disabled 21:29:57 svc:/system/iscsitgt:default
# svcadm enable stmf
# svcs stmf
STATE STIME FMRI
online 21:30:55 svc:/system/stmf:default
# stmfadm list-state
Operational Status: online
Config Status : initialized

Next I created a new small zfs volume.
(My zfs pool is named 'rz2pool' - it's Raidz2 - dual parity.)

# zfs create -V 4g rz2pool/iscsi_lun1

And then created a 'logical unit', using the zvol as it's backing store.

# sbdadm create-lu /dev/zvol/rdsk/rz2pool/iscsi_lun1

Created the following LU:

GUID DATA SIZE SOURCE
-------------------------------- ------------------- ----------------
600144f00008278f04694a5cf0980001 4294901760 /dev/zvol/rdsk/rz2pool/iscsi_lun1

# stmfadm list-lu -v
LU Name: 600144F00008278F04694A5CF0980001
Operational Status: Online
Provider Name : sbd
Alias : /dev/zvol/rdsk/rz2pool/iscsi_lun1
View Entry Count : 0

Now using the GUID of the logical unit, we make it visible to any initiators, by adding a 'view'

# stmfadm add-view 600144f00008278f04694a5cf0980001
# stmfadm list-view -l 600144f00008278f04694a5cf0980001
View Entry: 0
Host group : All
Target group : All
LUN : 0

Next we need to do the iscsi part, for which we need to install the iscsi target and the 'itadm' command. These were not already installed so I had to add the 'SUNWiscsit' package.

# pkg install -v SUNWiscsit
Creating Plan | Before evaluation:
UNEVALUATED:
+pkg:/SUNWiscsit@0.5.11,5.11-0.111:20090508T161047Z

After evaluation:
None -> pkg:/SUNWiscsit@0.5.11,5.11-0.111:20090508T161047Z
None -> pkg:/SUNWiscsidm@0.5.11,5.11-0.111:20090508T161041Z
Actuators:
restart_fmri: svc:/system/manifest-import:default
None
DOWNLOAD PKGS FILES XFER (MB)
Completed 2/2 23/23 0.66/0.66

PHASE ACTIONS
Install Phase 76/76
PHASE ITEMS
Reading Existing Index 8/8
Indexing Packages 2/2

# pkg list -v SUNWiscsit
FMRI STATE UFIX
pkg:/SUNWiscsit@0.5.11,5.11-0.111:20090508T161047Z installed ----
# pkg list -v SUNWiscsidm
FMRI STATE UFIX
pkg:/SUNWiscsidm@0.5.11,5.11-0.111:20090508T161041Z installed ----

On the next step I had a small problem.
(BTW, I am not using NWAM to configure my network card.)

# svcadm enable -r iscsi/target:default
svcadm: svc:/milestone/network depends on svc:/network/physical, which has multiple instances.

# svcs -a | grep network/physical
disabled Jul_09 svc:/network/physical:nwam
online Jul_09 svc:/network/physical:default

# svcadm enable iscsi/target
# svcs -a | grep iscsi
disabled Jul_09 svc:/network/iscsi_initiator:default
disabled 21:29:57 svc:/system/iscsitgt:default
maintenance 22:29:13 svc:/network/iscsi/target:default

# svcs -xv
svc:/network/iscsi/target:default (iscsi target)
State: maintenance since Tue Jul 14 22:29:13 2009
Reason: Start method failed repeatedly, last exited with status 4.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /usr/share/man -s 1M itadm
See: /var/svc/log/network-iscsi-target:default.log
Impact: This service is not running.

# tail /var/svc/log/network-iscsi-target\:default.log
[ Jul 14 22:29:13 Enabled. ]
[ Jul 14 22:29:13 Executing start method ("/lib/svc/method/iscsi-target start"). ]
iscsi-target: Requesting to enable iscsi target
open failed: INVALIDUnable to open device /devices/pseudo/iscsit@0:iscsit[ Jul 14 22:29:13 Method "start" exited with status 4. ]

Rebooting solved this problem.

# svcs -a | grep iscsi
disabled 19:25:15 svc:/network/iscsi_initiator:default
disabled 19:25:18 svc:/system/iscsitgt:default
online 19:25:37 svc:/network/iscsi/target:default

So now we create the iscsi target and check it looks ok:

# itadm create-target
Target iqn.1986-03.com.sun:02:7e969860-cb8d-475a-ddbb-97bf2f22ce7b successfully created

# itadm list-target -v
TARGET NAME STATE SESSIONS
iqn.1986-03.com.sun:02:7e969860-cb8d-475a-ddbb-97bf2f22ce7b online 0
alias: -
auth: none (defaults)
targetchapuser: -
targetchapsecret: unset
tpg-tags: default

I was then able to discover and logon to this iscsi target from a Windows 2003 server, using the Microsoft iscsi initiator.

The above is just the simplest possible configuration, just to allow some simple tests. For a more practical setup, you may well want multiple logical units, and want to put some restrictions on the views. But details on how to do that will have to wait for a follow-up post to this blog!

I did notice a couple of things fairly quickly. I saw the connection between the initiator and target was dropping every 50 seconds, followed immediately by a re-logon. Checking with WireShark showed that it was the target starting this with a [FIN, ACK]. With the old iscsi target I would have used DTrace to confirm this, but the iscsi target provider for the new iscsi target was not available.

I looked at the source code for the comstar iscsi target:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/comstar/port/iscsit/iscsit.c

.. and from the history link, I could see that a couple of likely fixes had already been committed:

26-May-2009 Priya Krishnan - 6809997 COMSTAR iscsi target DTrace Provider needed
08-May-2009 Peter Dunlap - 6755803 win2003 initiator numerous iscsi connection lost and connection retries mesgs to iscsi target

Now normally, I would hyper-link those bug number for you. But in this case there is no point, because Sun has chosen not to allows details of those bugs to be publicly available. (Or any of the other comstar iscsi target bugs AFAIK.)

Having those fixes is important for me, so it looks like I will have to update my OpenSolaris 2009-06 using the development repository to snv_118.

Tuesday, September 16, 2008

Progress on FISHworks?

Very little has been publicly announced by Sun about the FISHworks project.
After some initial news in early 2007, it seemed to go quiet.

Based on those reports, I would speculate that FISHworks appears to be a project to create a NAS/SAN appliance, based on existing OpenSolaris source code for ZFS, CIFS server, NFS server and the iScsi target, using DTrace observability to instrument under the hood.

At the start of September 2008, some more details about FISHworks emerged
when one of Sun's top engineers Mike Shapiro gave a video interview, bizarrely, on the noisy streets of San Francisco! It's a pity that this interview was conducted outside of a bar, as the background noise is somewhat distracting!

So when can we expect a proper announcement from Sun on FISHworks. Well according to the New York Time, that will be in November.

So do you want to know what progress is being made?

Then I suggest you check out the OpenSolaris bugs database.
This link shows bug activity in the iScsi target code for the last 30 days.

In the 'Reported Against' field, you will often see things like fw_36. This I believe is referring to FISHworks build 36.

Looking at the bugs for the last 30 days, there seems to be extensive & intensive testing happening of the OpenSolaris iScsi target, using various iScsi initiators and various operating systems, like Vista & Linux.

Some of the bugs looks quite obscure, occurring in relatively complex scenarios. Many of the bug comments refer to 'GRITS' and 'Diskomizer'. These seem to be Sun's internals tools for stress testing storage systems. Again, there does not seem to be much public information on these tools, but I googled and found these snippets on GRITS and Diskomizer.

It's good to see that in GRITS and Diskomizer, Sun seems to have the tools that
can expose these bugs. It's also good that these bugs are being fixed quickly.
Sun's Tim Szeto looks to have been particularly busy, and making good progress.

Some of the bug descriptions mention the 'Iwashi NAS appliance'
-So what it that? I would speculate maybe the code name for a Sun appliance?

Wednesday, February 21, 2007

Checking Solaris iScsi Performance with Dtrace

I've just discovered David Weibel's Blog and he has a couple of interesting posts regarding using dtrace(1M) to check performance issues with iScsi on Solaris.

David worked on the Solaris iScsi initiator code when he was at Sun Microsystems, Inc.

Wednesday, January 17, 2007

Using the NetBSD iScsi Target code on Solaris

The NetBSD iScsi target will, quite happily, compile and run on Solaris. The code was developed by Alistair Crooks, and is based on code released by Intel, under the BSD licence.

To try it out, I used the Belenix LiveCD distribution of OpenSolaris.
(root)# uname -a
SunOS belenix 5.11 BeleniX0.4.3 i86pc i386 i86pc
(root)# gcc -v
Reading specs from /usr/foss/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
(root)# cd tmp
(root)# curl -O http://www.alistaircrooks.co.uk/src/netbsd-iscsi-20060526.tar.gz
(root)# ls -l netbsd-iscsi-20060526.tar.gz
-rw------- 1 root root 239964 May 27 22:21 netbsd-iscsi-20060526.tar.gz
(root)# gunzip < netbsd-iscsi-20060526.tar.gz | tar xvf -
(root)# cd iscsi
(root)# cd src
(root)# ./configure
(root)# make
(root)# cd ../bin
(root)# ls -l
-rwx------ 1 root root 226580 May 27 22:24 iscsi-harness
-rwx------ 1 root root 219028 May 27 22:24 iscsi-target

I just wanted to use the iScsi target to confirm if the Microsoft iScsi initiator would work ok with it, and take some Ethereal traces of the initial login sequence. So I just used the following simple configuration file, which exports out a 100 mega byte file.
(root)# cat /etc/iscsi/targets
extent0 /tmp/iscsi-target0 0 100MB

target0 rw extent0 0.0.0.0/0
(root)# ./iscsi-target &
(root)# ls -l /tmp/iscsi-target0
-rw------- 1 root root 104857601 May 27 23:17 /tmp/iscsi-target0

I tried the target with v2.03 of the Microdoft iScsi initiator, and and I can report that every thing I tried worked ok.

You can browse the source code of the iScsi target at the NetBSD CVS server. To get the latest version of the code, it may be best to get it from the CVS server.

I've just noted that Alistair make some further changes to the code at the start of 2007, which are noted at this digest.

Sunday, January 14, 2007

Linux iScsi Target and the Inquiry LUN Response

Ok, last time we completed compiling and installing the Linux iScsi target. Now we need to configure it and start it. All I wanted to do, at this stage, was a simple test. So I just did the minimal amount of configuration. I was going to be running the target on Centos-4, running under VmWare, so it was easy to add a second virtual hard drive to the environment, in this case '/dev/sdb', to export out from the target.
# cat /etc/ietd.conf
#IncomingUser nwsmith secretsecret
Target iqn.2007-01.net.nwsmith:test01
Lun 0 /dev/sdb fileio
Alias iscsitest01

# service iscsi-target start
Starting iSCSI target service: [ OK ]

# netstat -ntlp | grep 3260
tcp 0 0 0.0.0.0:3260 0.0.0.0:* LISTEN 3160/ietd

# tail /var/log/messages
Jan 14 15:59:02 localhost kernel: iSCSI Enterprise Target Software - version 0.4.5
Jan 14 15:59:02 localhost kernel: iotype_init(91) register fileio
Jan 14 15:59:03 localhost kernel: target_param(109) d 1 8192 262144 65536 2 20 8 0
Jan 14 15:59:03 localhost iscsi-target: ietd startup succeeded

The Linux iScsi target seems to work fine with the Microsoft iScsi initiator (v2.03).

Ok, now we have the target running, one of the thing I wanted to look at was how the Linux iScsi target handled the initial login and connection from the Microsoft initiator. I was looking for how it handles the "Inquiry LUN" packet. I used Ethereal to capture and analyse the packets - filter on port 3260.

I had a look at the source code, and found what I was looking for in file "target_disk.c" and in function:
static int build_inquiry_response(struct iscsi_cmnd *cmnd)

By editing the values in this function, you can adjust the following fields in the response packet:

Version, Flags, Vendor Id:, Product Id:, Product Revision Level:

I tried changing some of these fields in the code, recompiling, restarting the target, and then used Ethereal to check that the response (from the target) to the (initiators) 'Inquiry' LUN packet changed as expected. And it did what I expected. (To change the Version returned, edit the line "data[2] = 3;").

The Version field indicates which version of SCSI is supported by the target. You can check which values are valid by reading the specification. The specification is called "SCSI Primary Commands - 3" or SPC-3 and you can download it from www.t10.org.

In the case of the version field, the valid values are shown in table 84:
0x00 - The device does not claim conformance to any standard.
0x02 - Obsolete.
0x03 - The device complies to ANSI INCITS 301-1997 (SPC).
0x04 - The device complies to ANSI INCITS 351-2001 (SPC-2).
0x05 - The device complies to T10/1416-D (SPC-3).

Ok, I think that's enough detail for this post.

Saturday, January 13, 2007

Centos 4 and the Linux iScsi Target

I wanted to do some tests with the Microsoft iScsi initiator and the Linux iScsi target, but first I had to install and configure the target. I had Centos 4.4 (a RHEL4 Linux clone) setup in VmWare, so i thought that using that would be the easy way to do the test.

I had read in PcPro magazine, last year, issue 137 (March 2006) page 197, that the Linux iScsi target would compile & install on Centos-4, but they did not say exactly which version they used.

Ok, so I download the latest version "iscsitarget-0.4.14.tar.gz".

I knew there was a potential problem, as the README file said it needed kernel version of 2.6.14 or newer, and the CONFIG_CRYPTO_CRC32C option had to be enabled. Centos 4.4 uses kernel 2.6.9, but with many additional patches from latter kernels, and the PCpro people said it would be ok.

Ok, so lets try it:

# cat /etc/redhat-release
CentOS release 4.4 (Final)
# uname -a
Linux localhost.localdomain 2.6.9-42.0.3.EL #1 Fri Oct 6 05:59:54 CDT 2006 i686 i686 i386 GNU/Linux
# cat /usr/src/kernels/2.6.9-42.0.3.EL-i686/crypto/Kconfig | grep -A 6 CRC
config CRYPTO_CRC32C
tristate "CRC32c CRC algorithm"
depends on CRYPTO
select LIBCRC32C
help
Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used
by iSCSI for header and data digests and by others.
See Castagnoli93. This implementation uses lib/libcrc32c.
Module will be crc32c.

# cd /home
# tar xfz iscsitarget-0.4.14.tar.gz
# chown -R root:root iscsitarget-0.4.14
# ll
drwxr-xr-x 7 root root 4096 Oct 19 10:48 iscsitarget-0.4.14
-rw-r--r-- 1 root root 92608 Mar 14 2006 iscsitarget-0.4.14.tar.gz
# cd iscsitarget-0.4.14
# export KERNELSRC=/usr/src/kernels/2.6.9-42.0.3.EL-i686/
# make
make -C usr
make[1]: Entering directory `/home/iscsitarget-0.4.14/usr'
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietd.o ietd.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o iscsid.o iscsid.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o conn.o conn.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o session.o session.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o target.o target.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o message.o message.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ctldev.o ctldev.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o log.o log.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o chap.o chap.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o event.o event.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o param.o param.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o plain.o plain.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o isns.o isns.c
cc ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o chap.o event.o param.o plain.o isns.o -o ietd -lcrypto
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietadm.o ietadm.c
cc ietadm.o param.o -o ietadm
make[1]: Leaving directory `/home/iscsitarget-0.4.14/usr'
make -C /lib/modules/2.6.9-42.0.3.EL/build SUBDIRS=/home/iscsitarget-0.4.14/kernel modules
make[1]: Entering directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'
CC [M] /home/iscsitarget-0.4.14/kernel/tio.o
CC [M] /home/iscsitarget-0.4.14/kernel/iscsi.o
CC [M] /home/iscsitarget-0.4.14/kernel/nthread.o
CC [M] /home/iscsitarget-0.4.14/kernel/wthread.o
CC [M] /home/iscsitarget-0.4.14/kernel/config.o
/home/iscsitarget-0.4.14/kernel/config.c:312: error: unknown field `unlocked_ioctl' specified in initializer
/home/iscsitarget-0.4.14/kernel/config.c:312: warning: initialization from incompatible pointer type
/home/iscsitarget-0.4.14/kernel/config.c:313: error: unknown field `compat_ioctl' specified in initializer
/home/iscsitarget-0.4.14/kernel/config.c:313: warning: initialization from incompatible pointer type
make[2]: *** [/home/iscsitarget-0.4.14/kernel/config.o] Error 1
make[1]: *** [_module_/home/iscsitarget-0.4.14/kernel] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'
make: *** [mods] Error 2

# cat /home/iscsitarget-0.4.14/kernel/config.c | grep -n ioctl
219:static long ioctl(struct file *file, unsigned int cmd, unsigned long arg)
312: .unlocked_ioctl = ioctl,
313: .compat_ioctl = ioctl,

Oops! It failed to compile.
Ok, let's google around and see who else has this problem...

It seems other people are getting the same sort of problem with the target versions 4.13 and 4.12 and the older Centos kernel 2.6.9-22.EL

I found this link, where you can download a patch for the target version 0.4.12, which should allow it to compile on kernel 2.6.9, but I did not try it, as it's a "quick hack - Use at your own risk". Maybe someone else can try this patch and give a report.

Ok, so should I dump Centos-4 for now and install Fedora 6, which has an up-to-date kernel. Or should I try and work out which version of the target it was that the Pcpro guy's were using? Ok, I choose the latter.

I went back and downloaded the older versions of the target. And to cut a long story short, I discovered that this version "iscsitarget-0.4.5.tar.gz" will compile on Centos-4. (If you look at the README for that version of the target, it says it is happy with kernel 2.6.10)
Here is the proof that it compiles:

# tar xfz iscsitarget-0.4.5.tar.gz
# chown -R root:root iscsitarget-0.4.5
# cd iscsitarget-0.4.5
# make
make -C usr
make[1]: Entering directory `/home/iscsitarget-0.4.5/usr'
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietd.o ietd.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o iscsid.o iscsid.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o conn.o conn.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o session.o session.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o target.o target.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o message.o message.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ctldev.o ctldev.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o log.o log.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o md5.o md5.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o isns.o isns.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o sha1.o sha1.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o chap.o chap.c
cc ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o md5.o isns.o sha1.o chap.o -o ietd
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include -c -o ietadm.o ietadm.c
cc ietadm.o ctldev.o -o ietadm
make[1]: Leaving directory `/home/iscsitarget-0.4.5/usr'
make -C /usr/src/kernels/2.6.9-42.0.3.EL-i686/ SUBDIRS=/home/iscsitarget-0.4.5/kernel modules
make[1]: Entering directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'
CC [M] /home/iscsitarget-0.4.5/kernel/tio.o
CC [M] /home/iscsitarget-0.4.5/kernel/iscsi.o
CC [M] /home/iscsitarget-0.4.5/kernel/nthread.o
CC [M] /home/iscsitarget-0.4.5/kernel/wthread.o
CC [M] /home/iscsitarget-0.4.5/kernel/config.o
CC [M] /home/iscsitarget-0.4.5/kernel/digest.o
CC [M] /home/iscsitarget-0.4.5/kernel/conn.o
CC [M] /home/iscsitarget-0.4.5/kernel/session.o
CC [M] /home/iscsitarget-0.4.5/kernel/target.o
CC [M] /home/iscsitarget-0.4.5/kernel/volume.o
CC [M] /home/iscsitarget-0.4.5/kernel/iotype.o
CC [M] /home/iscsitarget-0.4.5/kernel/file-io.o
CC [M] /home/iscsitarget-0.4.5/kernel/target_disk.o
LD [M] /home/iscsitarget-0.4.5/kernel/iscsi_trgt.o
Building modules, stage 2.
MODPOST
CC /home/iscsitarget-0.4.5/kernel/iscsi_trgt.mod.o
LD [M] /home/iscsitarget-0.4.5/kernel/iscsi_trgt.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.9-42.0.3.EL-i686'

# make install
`usr/ietd' -> `/usr/sbin/ietd'
`usr/ietadm' -> `/usr/sbin/ietadm'
if [ -f /etc/debian_version ]; then \
install -v -m 755 etc/initd/initd.debian /etc/init.d/iscsi-target; \
elif [ -f /etc/redhat-release ]; then \
install -v -m 755 etc/initd/initd.redhat /etc/init.d/iscsi-target; \
elif [ -f /etc/slackware-version ]; then \
install -v -m 755 etc/initd/initd /etc/rc.d/iscsi-target; \
else \
install -v -m 755 etc/initd/initd /etc/init.d/iscsi-target; \
fi
`etc/initd/initd.redhat' -> `/etc/init.d/iscsi-target'
install: creating directory `/lib/modules/2.6.9-42.0.3.EL/kernel/iscsi'
`kernel/iscsi_trgt.ko' -> `/lib/modules/2.6.9-42.0.3.EL/kernel/iscsi/iscsi_trgt.ko'
depmod -aq
#

Version 0.4.5 was released on 2005-02-21, so that PcPro article must have been on the editors desk for a year!

Ok, I still need to see if it will work, but that something for another post!