state of iscsi_initiator?
Johan Ström
I'm looking into FreeBSDs iSCSI initiator capabilities, and I'm
wondering how stable/used this is? Judging from the commits (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/iscsi/initiator/
) there haven't been very much (iSCSI specific) activity since
imported 14 months ago. Either nobody is using it thus not reporting
bugs, or it is working very well ;)
So, what I'm wondering is, how stable is this? Anyone using it
successfully in production? Checking this list's archive I've seen
some people with deadlock problems, but are there anyone using it
without these problems? Or is the userbase that small?
How about performance?
Thanks!
--
Johan
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi...@freebsd.org"
Andrew Snow
I'm just playing with iSCSI now, on a fresh 7.1-STABLE machine connected
to another FreeBSD box running ports/net/iscsi-target.
I am using the latest version 2.1 Initiator from:
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/
It seems alot better now than when I last tried it. The speed is
constant at around 50MB/s for a single sequential read or write. It
also reconnected very quickly when I restarted the target. I was even
able to reboot the target box and I/O resumed perfectly once it finished
booting!
The speed increased to 80mb/s when I ran two threads, which is close to
the max performance for the network cards in this machine.
A couple of minor issues:
1. Trouble shutting down iscontrol - after I kill -9 it stays around
for a minute or more until it finally goes away.
2. Under very heavy multi-threaded load, the client machine gets
sluggish to respond, even to keystrokes on the console. And if I
shutdown the target, even local disk accesses on the client computer
stop working after a while.
(I don't think this is a problem with iSCSI initiator. I suspect
there's something in FreeBSD which pauses all disk I/O if the length of
outstanding requests is too high, can anyone shed some light on this?)
Overall, a pleasant experience and shows how much good work has been
done on iSCSI. Congratulations Danny :-)
- Andrew
Danny Braniss
> I'm just playing with iSCSI now, on a fresh 7.1-STABLE machine connected
> to another FreeBSD box running ports/net/iscsi-target.
>
> I am using the latest version 2.1 Initiator from:
> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/
>
> It seems alot better now than when I last tried it. The speed is
> constant at around 50MB/s for a single sequential read or write. It
> also reconnected very quickly when I restarted the target. I was even
> able to reboot the target box and I/O resumed perfectly once it finished
> booting!
>
> The speed increased to 80mb/s when I ran two threads, which is close to
> the max performance for the network cards in this machine.
>
>
> A couple of minor issues:
>
> 1. Trouble shutting down iscontrol - after I kill -9 it stays around
> for a minute or more until it finally goes away.
>
you should kill -1, this does an orderly shutdown of the connection.
I guess an update to the manual is needed.
> 2. Under very heavy multi-threaded load, the client machine gets
> sluggish to respond, even to keystrokes on the console. And if I
> shutdown the target, even local disk accesses on the client computer
> stop working after a while.
>
> (I don't think this is a problem with iSCSI initiator. I suspect
> there's something in FreeBSD which pauses all disk I/O if the length of
> outstanding requests is too high, can anyone shed some light on this?)
>
I've noticed slugishness when a heavy fsck is running in the background - not
iscsi related, so it seems that heavy disk IO is using up resources, but
then again, the CPU is working :-)
>
> Overall, a pleasant experience and shows how much good work has been
> done on iSCSI. Congratulations Danny :-)
>
thanks,
danny
Johan Ström
>>
>> I'm just playing with iSCSI now, on a fresh 7.1-STABLE machine
>> connected
>> to another FreeBSD box running ports/net/iscsi-target.
>>
>> I am using the latest version 2.1 Initiator from:
>> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/
>>
>> It seems alot better now than when I last tried it. The speed is
>> constant at around 50MB/s for a single sequential read or write. It
>> also reconnected very quickly when I restarted the target. I was
>> even
>> able to reboot the target box and I/O resumed perfectly once it
>> finished
>> booting!
>>
>>
>> The speed increased to 80mb/s when I ran two threads, which is
>> close to
>> the max performance for the network cards in this machine.
Nice, I guess. Wonder how much one can get up to with 1GBit.. Altough
then I guess thats when the disks will be the limiting factor.
As for recovery, that have been working pretty nice for me to, I've
been running 2 VMWare machines here (on the same physcal box), one
with OpenFiler and one with 7.0-STABLE (and 2.0.99 iscsi).
I've been running iozone for a couple of hours, without any crashes or
so at least. I also tried rebooting the openfiler in the middle of
the iozone process with the following results (where the numbers are
iozone output):
2048 128 2111 3961 2547261 2190626
2048 256 4405 4363 2443638 2233342
2048 512iscontrol[3687]: trapped signal 30
trapped signal 30
iscontrol: supervise going down
iscontrol[3687]: sess flags=2000040d
iscontrol[3687]: Reconnect
errno=61
connect: Connection refused
iscontrol[3687]: Reconnect
iscontrol: supervise starting main loop
21 4271 1391257 2098062
2048 1024 4053 4151 2389263 4113514
2048 2048 3634 5330 2233342 3475985
4096 4 2860 3947 1648862 1836000
Yes iscontrol was started from the same console earlier. Regarding
that, I noticed that the 2.1 version had a daemonized version. is
there any changelog for 2.1?
>>
>>
>>
>> A couple of minor issues:
>>
>> 1. Trouble shutting down iscontrol - after I kill -9 it stays
>> around
>> for a minute or more until it finally goes away.
>>
>
> you should kill -1, this does an orderly shutdown of the connection.
> I guess an update to the manual is needed.
>
>> 2. Under very heavy multi-threaded load, the client machine gets
>> sluggish to respond, even to keystrokes on the console. And if I
>> shutdown the target, even local disk accesses on the client computer
>> stop working after a while.
If you take the target back up, does it wake up again?
>>
>>
>> (I don't think this is a problem with iSCSI initiator. I suspect
>> there's something in FreeBSD which pauses all disk I/O if the
>> length of
>> outstanding requests is too high, can anyone shed some light on
>> this?)
>>
> I've noticed slugishness when a heavy fsck is running in the
> background - not
> iscsi related, so it seems that heavy disk IO is using up resources,
> but
> then again, the CPU is working :-)
Thanks for your input :)