[Open-FCoE] Actual data transfer (FCoE)

hansraj Jadhav hansrajpict at gmail.com
Wed Jan 21 12:14:30 UTC 2009


Thanks Deepak,

It worked.. gr8 !!
I can now see the size as 100 MB.
*
*Output of ls -l
ls -l /target/mydisk
-rw-r--r-- 1 root root *104857600* Jan 21 01:55 /target/mydisk

Now,
How do i do actual data transfer on these disks once i m able to see them on
the initiator.? :)

Regards
Hansraj

On Wed, Jan 21, 2009 at 5:04 PM, Deepak Tawri <deepak at netxen.com> wrote:

> Hi,
>
> Can you try if=/dev/zero instead of if=/dev/null ?
> i.e.
>
> dd if=/dev/zero of=/target/mydisk bs=1M count=100 2>/dev/null
>
> Also, what is the output of "ls -l /target/mydisk" ?
>
> thanks,
> deepak
>
> hansraj Jadhav wrote:
>
>> Hi Joe,
>>
>> Im creating LUNS on the target.
>> + This is the command i use:
>>
>> *dd if=/dev/null of=/target/mydisk bs=1M count=100 2>/dev/null
>>
>> echo "open mydisk /target/mydisk" > /proc/scsi_tgt/vdisk/vdisk
>>
>> *+ It shows the size of mydisk as zero.
>>
>> Name              *Size(MB)*    Block size  Options         File name
>> mydisk            * 0  *               512
>> /target/mydisk
>>
>> Is this the problem?
>>
>> @Robert
>> The* fdisk -l* on the inititator shows only the physical disks attached.
>> It does not show any other disks.
>> I can see the Luns when i do a "cat /proc/scsi/scsi"  &
>> I can also see new devices if i do " ls /dev/s* ".
>>
>> + Please find the text file below.
>>
>> Regards
>> Hansraj
>>
>>
>>
>>
>> On Wed, Jan 21, 2009 at 12:44 AM, Joe Eykholt <jre at nuovasystems.com>
>> wrote:
>>
>>  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
>>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> devel mailing list
>> devel at open-fcoe.org
>> http://www.open-fcoe.org/mailman/listinfo/devel
>>
>
>


-- 
!!! Never Say Die !!!



More information about the devel mailing list