[Open-FCoE] Actual data transfer (FCoE)

Robert Love robert.w.love at linux.intel.com
Tue Jan 20 17:26:53 UTC 2009


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.

> 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