Re: Abort Task ?

[Ming Zhang <blackmagic02881@gmail.com>]

On Fri, 2007-10-19 at 16:30 +0200, BERTRAND Joël wrote:
> Ming Zhang wrote:
> > On Fri, 2007-10-19 at 09:48 +0200, BERTRAND Joël wrote:
> >> Ross S. W. Walker wrote:
> >>> BERTRAND Joël wrote:
> >>>> BERTRAND Joël wrote:
> >>>>>     I can format serveral times (mkfs.ext3) a 1.5 TB volume 
> >>>> over iSCSI 
> >>>>> without any trouble. I can read and write on this virtual 
> >>>> disk without 
> >>>>> any trouble.
> >>>>>
> >>>>>     Now, I have configured ietd with :
> >>>>>
> >>>>> Lun 0 Sectors=1464725758,Type=nullio
> >>>>>
> >>>>> and I run on initiator side :
> >>>>>
> >>>>> Root gershwin:[/dev] > dd if=/dev/zero of=/dev/sdj bs=8192
> >>>>> 479482+0 records in
> >>>>> 479482+0 records out
> >>>>> 3927916544 bytes (3.9 GB) copied, 153.222 seconds, 25.6 MB/s
> >>>>>
> >>>>> Root gershwin:[/dev] > dd if=/dev/zero of=/dev/sdj bs=8192
> >>>>>
> >>>>>     I'm waitinfor a crash. No one when I write these lines. 
> >>>>    I suspect 
> >>>>> an interaction between raid and iscsi.
> >>>> 	I simultanely run :
> >>>>
> >>>> Root gershwin:[/dev] > dd if=/dev/zero of=/dev/sdj bs=8192
> >>>> 8397210+0 records in
> >>>> 8397210+0 records out
> >>>> 68789944320 bytes (69 GB) copied, 2732.55 seconds, 25.2 MB/s
> >>>>
> >>>> and
> >>>>
> >>>> Root gershwin:[~] > dd if=/dev/sdj of=/dev/null bs=8192
> >>>> 739200+0 records in
> >>>> 739199+0 records out
> >>>> 6055518208 bytes (6.1 GB) copied, 447.178 seconds, 13.5 MB/s
> >>>>
> >>>> 	without any trouble.
> >>> The speed can definitely be improved. Look at your network setup
> >>> and use ping to try and get the network latency to a minimum.
> >>>
> >>> # ping -A -s 8192 172.16.24.140
> >>> ....
> >>> --- 172.16.24.140 ping statistics ---
> >>> 14058 packets transmitted, 14057 received, 0% packet loss, time 9988ms
> >>> rtt min/avg/max/mdev = 0.234/0.268/2.084/0.041 ms, ipg/ewma 0.710/0.260 ms
> >> gershwin:[~] > ping -A -s 8192 192.168.0.2
> >> PING 192.168.0.2 (192.168.0.2) 8192(8220) bytes of data.
> >> 8200 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.693 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.595 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.583 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=0.589 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=0.580 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=0.594 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=7 ttl=64 time=0.580 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=8 ttl=64 time=0.592 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=9 ttl=64 time=0.589 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=10 ttl=64 time=0.571 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=11 ttl=64 time=0.588 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=12 ttl=64 time=0.580 ms
> >> 8200 bytes from 192.168.0.2: icmp_seq=13 ttl=64 time=0.587 ms
> >>
> >> --- 192.168.0.2 ping statistics ---
> >> 13 packets transmitted, 13 received, 0% packet loss, time 2400ms
> >> rtt min/avg/max/mdev = 0.571/0.593/0.693/0.044 ms, ipg/ewma 200.022/0.607 ms
> >> gershwin:[~] >
> >>
> >> 	Both initiator and target are alone on a gigabit NIC (Tigon3). On 
> >> target server, istd1 takes 100% of a CPU (and only one CPU, even my 
> >> T1000 can simultaneous run 32 threads). I think the limitation comes 
> >> from istd1.
> > 
> > usually istdx will not take 100% cpu with 1G network, especially when
> > using disk as back storage, some kind of profiling work might be helpful
> > to tell what happened...
> > 
> > forgot to ask, your sparc64 platform cpu spec.
> 
> Root gershwin:[/mnt/solaris] > cat /proc/cpuinfo
> cpu             : UltraSparc T1 (Niagara)
> fpu             : UltraSparc T1 integrated FPU
> prom            : OBP 4.23.4 2006/08/04 20:45
> type            : sun4v
> ncpus probed    : 24
> ncpus active    : 24
> D$ parity tl1   : 0
> I$ parity tl1   : 0
> 
> 	Both servers are built with 1 GHz T1 processors (6 cores, 24 threads).
> 

as Ross pointed out, many io pattern only have 1 outstanding io at any
time, so there is only one work thread actively to serve it. so it can
not exploit the multiple core here.


you see 100% at nullio or fileio? with disk, most time should spend on
iowait and cpu utilization should not high at all.


 
> 	Regards,
> 
> 	JKB
-- 
Ming Zhang


@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel