[Open-FCoE] Actual data transfer (FCoE)

Joe Eykholt jre at nuovasystems.com
Tue Jan 20 19:18:33 UTC 2009


[resending due to a mailer problem]

Robert Love wrote:
> On Tue, 2009-01-20 at 21:37 +0530, hansraj Jadhav wrote:
>> 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.
>>
> Unfortunately I don't get the attachment. I have two accounts subscribed
> to this list and I don't get it on either. 
> 
> What does 'fdisk -l' show on the initiator side? If you're seeing dev nodes on the initiator you must be connecting to your target and SCSI must be talking to the LUNs. I'm curious if
they're showing any capacity though, fdisk should answer that.

Robert, you guessed the problem I think.  The sense
says the LBA is out of range, so LUN 0 has no capacity.  This isn't too unusual.
Hansraj, maybe you used another LUN number for the disk, but in any case, the problem
is on the target side.

Here's the end of your trace with my comments:

 3  11.083730     01.01.01 -> 01.02.00     FCP SCSI: Read(10) LUN: 0x00 (LBA: 0x00000000,
Len: 1)

0000  0e fc 00 01 02 00 0e fc 00 01 01 01 89 06 00 00   ................
0010  00 00 00 00 00 00 00 00 00 00 00 2e 06 01 02 00   ................
0020  00 01 01 01 08 29 00 00 00 00 00 00 01 2f ff ff   .....)......./..
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02   ................
0040  28 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00   (...............
0050  00 00 02 00 08 67 54 bf 42 00 00 00               .....gT.B...

  4  11.084619     01.02.00 -> 01.01.01     FCP SCSI: Response LUN: 0x00 (Read(10)) (Check
Condition) LUN:0x00

0000  0e fc 00 01 01 01 0e fc 00 01 02 00 89 06 00 00   ................
0010  00 00 00 00 00 00 00 00 00 00 00 2e 07 01 01 01   ................
0020  00 01 02 00 08 98 00 00 66 00 00 00 01 2f 4b e0   ........f..../K.
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 02   ................
#                                         sense start 70 key 5
0040  00 00 02 00 00 00 00 1a 00 00 00 00 70 00 05 00   ............p...
#     4  5  6  7 addl len a    additional sense code 21
#                 8  9  10 11 12 13 14 15 16 17 18 19
0050  00 00 00 0a 00 00 00 00 21 00 00 00 00 00 00 00   ........!.......
#      2  3  4  5  6  7  8  9 10 11 12 13 14 15
0060  00 00 00 00 00 00 00 02 00 94 91 51 42 00 00 00   ...........QB...


>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at open-fcoe.org
>> http://www.open-fcoe.org/mailman/listinfo/devel
> 





More information about the devel mailing list