Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: iSCSI



On Thu, 25 Feb 2010, Chavdar Ivanov wrote:
On 25 February 2010 09:06, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
On 18 February 2010 19:58, Stephen Borrill <netbsd%precedence.co.uk@localhost> 
wrote:
On Thu, 18 Feb 2010, Martti Kuparinen wrote:

I need to setup iSCSI target and I was wondering how
good/stable/complete/fast the iSCSI support is in NetBSD 5.99.x. All
comments are welcome, especially if you use it with VMware ESXi 4.0.

In-tree iscsi target is fast and stable, but low on features.

I've got two machines setup as iSCSI targets; the initiator is Windows
2008R2. One of them, serving three raw disks, never fails (still on
$ uname -a
NetBSD support9 5.99.24 NetBSD 5.99.24 (GENERIC) #0: Tue Feb  2
16:51:41 GMT 2010
root@uksup2:/usr/obj/usr-current/i386/sys/arch/i386/compile/GENERIC
i386 )

The other, with slightly newer kernel (but the same has been happening
for quite some time), serving 7 wedges, to the same initiator,
regularly dumps core when the initiator reboots:

Did you spot the -s option which fixed all manner of core dumps as my number of targets grew?

I've used it
as a backend for a Xen farm. However, adding a LUN requires a restart of the
daemon which causes havoc. I've also found it to not work with a Linux
initiator (or more specifically XenServer).

That's why I imported net/istgt which is used in FreeNAS and looks, on the
basis of my initial experiments, to be ideal.

I've started to consider switching to this; is there any documentation
other than the example .conf files available?

Strike this off; the .conf files are good enough.

Yes, at first glance it looks madly complex, but taking time out for a quiet sit-down and a few minute's reflection clears things up.

I switched to istgt on that machine with no problems.

I've had it reported that 'our' iscsifs initiator is incompatible with istgt (by istgt's author):

"In my quick review of the code, at least, I found following bugs:
does not accept CHAP challenge length other than 16 octets. (force exit)
does not handle NOP-OUT CmdSN and immediate bit. (incorrect request)
does not handle NOP-IN TransferTag=0xffffffff. (segfault)
does not handle Underflow bit in iSCSI response. (force exit)
does not set media size properly. (incorrect mount or segfault)"

Fixing iscsifs to work with istgt may well have the happy side effect of making it work with other currently incompatible targets (e.g. IBM DS3300 storage).


--
Stephen


Home | Main Index | Thread Index | Old Index