[Open-FCoE] Actual data transfer (FCoE)

hansraj Jadhav hansrajpict at gmail.com
Tue Jan 20 16:07:39 UTC 2009


Hi Joe,

Thanks for your quick response.

I tried out the instructions mentioned.
+ I checked the pause and set the tx and the rx 'on' and autoneg ' off '.
+ I also tried
dd if=/dev/sdXX of=/dev/null count=100 iflag=direct

dd: reading `/dev/sdc': *Input/output error*
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.00198219 seconds, 0.0 kB/s

+ Please find a text file, captured using tshark.

Regards
Hansraj



---------- Forwarded message ----------
From: Joe Eykholt <jre at nuovasystems.com>
Date: Tue, Jan 20, 2009 at 3:00 PM
Subject: Re: [Open-FCoE] Actual data transfer (FCoE)
To: hansraj Jadhav <hansrajpict at gmail.com>
Cc: devel at open-fcoe.org


hansraj Jadhav wrote:

> Hi all,
>
> + Im using the Open FCoE initiator.
>   Im creating virtual LUNS on the target. and i m also able to see these
> luns
>  on the initiator when i do a
>  cat /proc/scsi/scsi.
>
> + Im stuck here, how do i see an actual data transfer from the initiator to
> the target.
> + I also tried doing mkfs on the Luns discovered, but it failed after some
> time.
>
>
>
> Thanks,
> Hansraj
>
>
Hi Hansraj,

First, be sure you have Ethernet link pause autonegotiated or
turned on for both nodes and a point-to-point connection
with no switch in the middle unless it supports lossless behavior
(very few do).  You can check pause with 'ethtool -a ethX'.
It should show 'tx on rx on' for both sides.  If not, do
'ethtool -A ethX auto off tx on rx on'  If your NICs do not support
pause, you could very well have data transfer problems.  Although
SCSI will retry the operations, if the data overruns, it could
overrun on the retry attempts indefinitely.

Second, the drives should work just like any other disk device.
Try doing reads with dd on the disks.  If you do
'dd if=/dev/sdXX of=/dev/null count=100 iflag=direct' you will
get 100, 512-byte reads.  The 'iflag=direct' bypasses the buffer
cache to make sure they are real I/Os after the first time.
Of course, substitute your actual drive for /dev/sdXX.

You can switch this around to do writes and test for data integrity.
I make a random file and then copy it to the drive and
read it back like this:
       dd bs=64k count=100 if=/dev/urandom of=/tmp/patt
       dd bs=64k if=/tmp/patt of=/dev/sdXX oflag=direct
       dd bs=64k if=/dev/sdXX of=/tmp/read iflag=direct count=100
       cmp /tmp/patt /tmp/read

Since you had failures, I'm guessing the pause
issue is the problem.   Let me know how it goes.  If you still
have problems, you could send a small packet trace during the
failures gathered with:

tcpdump -i ethX -w trace.cap -s 300 -c 200 ether proto 0x8906

       Joe





-- 
!!! Never Say Die !!!


More information about the devel mailing list