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).
Regards,
JKB
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
