Re: istgt now supports command queuing in disk type
Hello, I sent change request of ports version. (just now was committed when I wrote mail) What's new? (from 20090323) o starting to support multipath I/O by VMware ESXi (Fix/MRU/RR) o wildcard address listen and translate IP (useful on DHCP) o utilization efficiency of the command queuing was improved o task abort handling in cluster nodes o reduce deadlock and timeout risk (from 20090314) o support command queuing o shrink pre-allocated SCSI sense data buffer from 64K to 4K. o allow full specify eui. and naa. like iqn. o if small PDU, write as one buffer. and many bug fixes The command queuing is disabled by default. If you want to use it, please add QueueDepth key in the LogicalUnit section of your configuration. for example: [LogicalUnit1] # Queuing 0=disabled, 1-255=enabled with specified depth. QueueDepth 16 If you have any problem with command queuing, comment out or specify 0 to disable it. Disabled version is about the same behavior as 20090314. To use wildcard address, edit your configuration like this: [PortalGroup1] # for IPv6 Portal DA1 [::]:3260 # for IPv4 Portal DA1 0.0.0.0:3260 Do not use mix with other IPs. After this change you can see TargetAddress as connected IP. IP address family connected by discovery session is important. If you need IPv6 target address, should use IPv6 in discovery. Also if you need IPv4 target address, should use IPv4. The istgt will reply only one IP address of multiple wildcard address to the initiator. Here is release 20090326: http://shell.peach.ne.jp/aoyama/archives/386 -- Daisuke Aoyama ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: istgt now supports command queuing in disk type
Hello, Daisuke. You wrote 23 марта 2009 г., 03:31:12: I got the result about 1.5x-3x faster than previous 20090314. If test data was cached, it reached over 200MB/s. I have one question: what do you mean when write, that this software is intended to use with ZFS? Could it be used to provide access to raw (disk) devices? Is it safe? Ok, it can have bugs, but is it as safe as access to file placed on ZFS (you test it in such configuration, am I right?)? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
istgt now supports command queuing in disk type
Hello. New release was uploaded in my blog. The command queuing improves especially sequential read by MCS(multiple connections per session) round robin. In my post, I uploaded the screen shots using CrystalDiskMark which is one of popular benchmark in Japan. You can download CrystalDiskMark(multilingual) from: http://crystalmark.info/?lang=en I got the result about 1.5x-3x faster than previous 20090314. If test data was cached, it reached over 200MB/s. Known Issue and Limitations: o queuing is only supported in single initiator environment. o LUN thread might have deadlock when an error has occurred. o write command is still slow. o timeout may occur when using MCS. o single connection may be slower than without queuing. Here is release 20090323: http://shell.peach.ne.jp/aoyama/archives/376 The screen shots show difference between QueueDepth 16 and 0 (disabled queuing). The command queuing is disabled by default. If you want to use it, please add QueueDepth key in the LogicalUnit section of your configuration. for example: [LogicalUnit1] # Queuing 0=disabled, 1-255=enabled with specified depth. QueueDepth 16 Thanks. -- Daisuke Aoyama ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
