Re: Sniffing FC traffic

[Thomas Glanzmann]

Hello Steve,

> We have had some success using a (Teledyne) LeCroy analyzer. Its GUI

I found a LeCroy FC analyzer on ebay for 500 EURs. I'm not buying it
yet, but keep it in mind. Much less the cost I had in mind (100 T EUR).

Cheers,
Thomas

Re: HBA recommended as FC target

[Thomas Glanzmann]

Hello Laurence,

* Laurence Oberman  [2017-08-18 15:26]:
> Any of the Qlogic qla24xx or qla25xx and higher that allow you to
> disable initiator mode will work.  I use qla25xx 8Gbit in all my
> Target arrays.

thank you for your recommendations I ordered a Qlogic QLE2462-HP
-PX2510401 - 4GB 2-Port Fibre on ebay.

* Laurence Oberman  [2017-08-18 15:31]:
> There is no way to do this using adapters and generic F/C with Linux
> as the O/S. The ability to enable debugging in the F/C drivers will
> expose some of the internals but there is no way to sniff directly as
> far as I am aware.

I enabled debugging in the Linux target once and I could see quiet
detailed information. Probably this will be enough for me. At the time I
was debugging SCSI reservations.

> Many switches allow port level tracing facilities but inline sniffing
> using Linux and generic hosts is not possible.

Are you aware of facilities in entry level brocade switches that I can
use. I just have to trace one port.

Cheers,
Thomas

Sniffing FC traffic

[Thomas Glanzmann]

Hello,
I would like to create a setup that allows me to sniff FC traffic. Is it
possible with Linux or can someone recommend a setup that works. I want
to avoid buying a 120kUSD fabric analyzer.

Cheers,
Thomas

HBA recommended as FC target

[Thomas Glanzmann]

Hello,
I look for a FC HBA that works with the Linux target. Can somone
recommend a HBA type to me?

Cheers,
Thomas

Re: some iscsi vendor has been hitting a crash

[Thomas Glanzmann]

Hello Mike,

* Mike Christie micha...@cs.wisc.edu [2013-11-01 15:56]:
 On a related note, some iscsi vendor has been hitting a crash with
 your tree.

I hit an 'IO stall' with the tree, but was not able to reproduce this.
Has this vendor information on it (dmesg, OOPS)? I reverted back to
RTSOS for production classes that I do not give myself, but will run the
Nab's tree as soon as I give a VMware class myself in order to reproduce
the issue and than track it down.

Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: some iscsi vendor has been hitting a crash

[Thomas Glanzmann]

Hallo Nab,

 Mike's talking about the WIP scsi-mq - blk-mq initiator stack here,
 and not specifically about anything related to target code.

I see. Thanks. I'll keep you posted.

Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] target: EXTENDED_COPY bugfixes for v3.12-rc

[Thomas Glanzmann]

Hello Nab,

   target: Make target_do_xcopy failures return INVALID_PARAMETER_LIST
   target: Allow non zero ListID in EXTENDED_COPY parameter list
   target: Reject EXTENDED_COPY when emulate_3pc is disabled

I pull them right now, rebuild and test them tomorrow in my currently
ongoing class. I'll report back by the end of the week if there have
been any problems, but I assume there will not be. I also wondered why
you allowed xcopy when the feature was not enabled, but never bothered
to ask. :-) However I'm still fighting with the demo mode discovery, I
should know the code by now.

Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xcopy testing with ddpt

[Thomas Glanzmann]

Hello Doug,

* Douglas Gilbert dgilb...@interlog.com [2013-10-07 00:58]:
 Great, another one working.

yes. :-)

 So this saniq/HP/lefthand system does not support fetching
 the xcopy operating parameters, which will cause sg_xcopy
 and ddpt to give up. These could be defaulted to something
 sane and then use those default values to attempt the
 command that actually does the work:  EXTENDED_COPY(LID1).
 Googled around and couldn't find any workflow for this (for
 the saniq product). Do you have any technical documentation
 for this product that might throw some light on this?

I don't have any technical documentation describing EXTENDED_COPY.
However I know that it works with ESX server. So what I did is sniffing
the SCSI commands. Find the pcap here:

https://thomas.glanzmann.de/tmp/xcopy.pcap.bz2 (920K)
https://thomas.glanzmann.de/tmp/onexcopy.pcap (4K)

Hopefully that helps you figure out what is going on. My first though
was that we were doing the 100 MB in 4 chunks. That means approx 25 MB
per chunk (not precisely). However maybe that is to much for the SAN/IQ.
Maybe we should go easy on it and try 4 MB or 16 MB chunks. I have
configured the ESX to 16 MB chunks (the maximum ESX supports) using the
following command:

esxcfg-advcfg -s 16384 /DataMover/MaxHWTransferSize

If you want access to the system using ssh, let me know.

 Good. Now sg_xcopy and ddpt (my versions) output debug lines
 like this:
  /dev/sdh: LEFTHAND  iSCSIDisk a500  [pdt=0, 3pc=1]

perfect.

   Unit serial number: ca7e1e04bb286ee443fe05e985a11d240019

 Interesting serial number :-)

no idea how they calculate it.

 BTW list_id=0 has a special meaning in some context
 (buried deep in T10 documents: spc4r36j.pdf). That is
 probably why Hannes Reinecke defaulted that list_id to
 1. I could understand the target XCOPY implementation
 only accepting one xcopy sequence at a time, but why
 restrict it to list_id=0 ? A question for NaB ...

Nab, do you have any input for us?

Quick wrap up what we did so far: Doug asked me to test ddpt and
sg_xcopy of sg3-utils beta on your target. After setting the list_id=0
both tools work out of the box. The test setup is:

- 2 100 MB LUNs
- Createing a filesystem on the first and copy some date on it
- Use

ddpt if=/dev/sg3 iflag=xcopy list_id=0 of=/dev/sg4 bs=512
sg_xcopy if=/dev/sdc of=/dev/sdd list_id=0

to copy the data from LUN 1 to LUN 2. And do a md5sum to verify
that the user data are exactly the same.

Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] target: Fixes for COMPARE_AND_WRITE backend I/O failure cases

[Thomas Glanzmann]

Hallo Nab,

 Please let me know if you encounter any issues, and a patch to address
 this bit should be along in the next 24-48 hours.

I just did a little bit of stress testing:

- Rescan from 12 Initiators at the same time - PASS
- Deployed 24 VMs over 12 Initiators at the same time 200 MB/s
  frontend traffic - PASS
- Booted 24 VMs on 12 ESX servers at the same time - 120 MB/s
  frontend traffic - PASS
- Did 24 svMotion at the same time - 400 MB/s backend traffic -
  10 MB/s frontend traffic using XCOPY. - PASS
- Unloaded the target in production, ran 'grep se_tmr
  /proc/slabinfo' and loaded it again. And made sure that the
  VMs continued to run. - PASS

It looks pretty stable to me. I'll use it next week in a class and
report back if I had any issues whatsoever. This was with:

v3.12-rc3-4-g8a77fe9

Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] target: Fixes for COMPARE_AND_WRITE backend I/O failure cases

[Thomas Glanzmann]

Hello Nab,

 Thomas, these are all fairly obvious fixes to me, and I've been able
 to confirm them on my setup.  Please confirm on your end, and I'll
 plan to push them for v3.12-rc4 by the end of the week.

I confirm that the fixes work. Thank you for fixing this. I did the
following:

- Applied the patches on top of your for-next, recompiled,
  installed modules and kernel got rid of
  '/lib/modules/3.11.0-rc5+/extra/' which contained target
  modules with an unknown symbol __dynamic_pr_debug (from the
  debug build, I assume)

- Started the target, discovered from two esx servers, created
  VMFS (no error), deployed one VM, used XCOPY to clone it three
  times, powered it on and did 4 svmotion in parallel.

So the fix works. I also have the feeling that the xcopy code became
faster, but I first have to meassure it.

I'll today some more testing with rescans from 12 ESX and svmotion
(XCOPY) of 24 VMs in parallel. But everything is looking good from my
site. I'm also working on the discovery patch.

Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html