iSCSI target used as a ZFS pool showing corruption after "zpool status"

Status
Not open for further replies.

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
I have created a 3TB zvol that I share as an ISCSI target to a Sun M3000 server running Solaris 10/9. The FreeNAS server and the M3000 server are connected by a 10GBASE-CX4 directly connected to each other with a good cable. Both the FreeNAS server and the M3000 server are for lab use in staging and replicating a customer operation environment with relatively large database (about 600G).

The M3000 creates a zpool using the ISCSI target. On this pool a ZFS filesystem is created and within that, a Solaris Zone is created. The zone is populated using 2 compressed TAR files containing the application operating code and a copy of the database.

This all works without errors including networking errors, I/O errors, ISCSI errors, or any error being reported by FreeNAS including scrubbing the pool with the zvol.

However from M3000 server, right after populating the zpool/filesystem, I run "zpool scrub", the pool reports a couple of checksum errors. I have no idea why this might be occurring. I have destroyed the pool, destroyed the vol on the FreeNAS server, recreated everything and still get a couple of checksum errors each time I set this up.

Any ideas will be greatly appreciated.

FreeNAS hardware:
FreeNAS version: FreeNAS-9.10.2-U1 (86c7ef5)

All of the Hitachi UltraStar drives have had SMART diagnostics run with no errors being reported.

Storage setup below. 2 of the SSD drives are used a the ZFS cache devices (one for each pool). The 3'rd SSD drive is the boot device. The 3 6TB drives are going to be just used as for backup storage usage.

Code:
[root@sanserver] ~# zpool list

NAME		   SIZE  ALLOC   FREE  EXPANDSZ   FRAG	CAP  DEDUP  HEALTH  ALTROOT

M0			7.25T   603G  6.66T		 -	12%	 8%  1.00x  ONLINE  /mnt

M1			7.25T  2.45G  7.25T		 -	 0%	 0%  1.00x  ONLINE  /mnt

S0			16.2T  6.12M  16.2T		 -	 0%	 0%  1.00x  ONLINE  /mnt

freenas-boot   232G   888M   231G		 -	  -	 0%  1.00x  ONLINE  -

[root@sanserver] ~# zpool status

  pool: M0

state: ONLINE

  scan: scrub repaired 0 in 1h50m with 0 errors on Tue Jun  6 22:46:53 2017

config:


	NAME											STATE	 READ WRITE CKSUM

	M0											  ONLINE	   0	 0	 0

	  mirror-0									  ONLINE	   0	 0	 0

		gptid/0bc62866-f213-11e6-b0a5-00074305936a  ONLINE	   0	 0	 0

		gptid/251782ff-f2fe-11e6-b22e-00074305936a  ONLINE	   0	 0	 0

	  mirror-1									  ONLINE	   0	 0	 0

		gptid/457367a0-f213-11e6-b0a5-00074305936a  ONLINE	   0	 0	 0

		gptid/491ef03c-f213-11e6-b0a5-00074305936a  ONLINE	   0	 0	 0

	  mirror-2									  ONLINE	   0	 0	 0

		gptid/e6a0d5ea-f216-11e6-b0a5-00074305936a  ONLINE	   0	 0	 0

		gptid/be224a19-f45b-11e6-9a35-00074305936a  ONLINE	   0	 0	 0

	  mirror-3									  ONLINE	   0	 0	 0

		gptid/1f491cbe-f21b-11e6-b0a5-00074305936a  ONLINE	   0	 0	 0

		gptid/233ecfb2-f21b-11e6-b0a5-00074305936a  ONLINE	   0	 0	 0

	cache

	  ada0p1										ONLINE	   0	 0	 0


errors: No known data errors


  pool: M1

state: ONLINE

  scan: scrub repaired 0 in 0h0m with 0 errors on Sun May  7 00:00:25 2017

config:


	NAME											STATE	 READ WRITE CKSUM

	M1											  ONLINE	   0	 0	 0

	  mirror-0									  ONLINE	   0	 0	 0

		gptid/9ad3caa1-13b0-11e7-9d6f-00074305936a  ONLINE	   0	 0	 0

		gptid/7fc6767b-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

	  mirror-1									  ONLINE	   0	 0	 0

		gptid/9836ff68-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/9c35cc68-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

	  mirror-2									  ONLINE	   0	 0	 0

		gptid/b1d1edef-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/b4d6bdce-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

	  mirror-3									  ONLINE	   0	 0	 0

		gptid/cf9d2d83-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/d27fc5b6-f559-11e6-ad35-00074305936a  ONLINE	   0	 0	 0

	cache

	  ada0p2										ONLINE	   0	 0	 0


errors: No known data errors


  pool: S0

state: ONLINE

  scan: scrub repaired 0 in 0h0m with 0 errors on Sun May 28 00:00:01 2017

config:


	NAME											STATE	 READ WRITE CKSUM

	S0											  ONLINE	   0	 0	 0

	  raidz1-0									  ONLINE	   0	 0	 0

		gptid/7850cb65-0413-11e7-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/792d7b32-0413-11e7-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/7a83c4db-0413-11e7-ad35-00074305936a  ONLINE	   0	 0	 0


errors: No known data errors

The FreeNAS filesystems look like.  Here is the "zfs list"

[root@sanserver ~]# zfs list

NAME												  USED  AVAIL  REFER  MOUNTPOINT

M0												   3.05T  3.97T	23K  /mnt/M0

M0/.system											417M  3.97T   402M  legacy

M0/.system/configs-ea02119b0df4495ba64ec1dbdd61ed06  8.62M  3.97T  8.62M  legacy

M0/.system/cores									  706K  3.97T   706K  legacy

M0/.system/rrd-ea02119b0df4495ba64ec1dbdd61ed06		23K  3.97T	23K  legacy

M0/.system/samba4									83.5K  3.97T  83.5K  legacy

M0/.system/syslog-ea02119b0df4495ba64ec1dbdd61ed06   4.85M  3.97T  4.85M  legacy

M0/jails											   23K  3.97T	23K  /mnt/M0/jails

M0/m3000space										3.05T  6.43T   601G  -

M1												   1016G  6.03T	23K  /mnt/M1

M1/debianspace									   1016G  7.02T  2.45G  -

S0												   3.91M  10.5T   117K  /mnt/S0

freenas-boot										  888M   224G   176K  none

freenas-boot/ROOT									 879M   224G   136K  none

freenas-boot/ROOT/Initial-Install					   8K   224G   848M  legacy

freenas-boot/ROOT/default							 879M   224G   874M  legacy

freenas-boot/grub									7.29M   224G  7.29M  legacy



The "M0/m3000space" is the zvol that is shared as the ISCSI target to the M3000.
 
Last edited by a moderator:

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
Thanks for the edit. I was just going to do this myself and thought maybe I was becoming senile and had already done it when I saw "Last edited by a moderator" :)

I will ensure to use the codes in future posts!
 

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
Let me ask this question a different way. If I have FreeNAS (with 64G of ECC memory) with a RAID10 pool with a VDEV within as an ISCSI target and

1. I an enterprise class machine running Solaris 10/9 (with ECC memory ;) as the ISCSI initiator
2. the ISCSI initiator creates a ZFS pool using the ISCSI target.
3. There is a dedicated 10G link between the ISCSI initiator and the FreeNAS server
4. There are no ISCSI disconnects, no network errors, no power failures, etc on either system
5. About 600G of files is written to the ZFS fileset in the pool
6. Immediately after writing the 600G of files, a "zfs scrub <poolname>" reports "Permanent errors have been detected in the following files" error.

This is repeatable each time. Different files are reported and just a couple are reported.

I have tried various things such as turn off compression on the "vdev", removed jumbo frames support for the network interface, etc. but still having an issue.

FreeNAS scrub on its pool where the VDEV resides shows no issues. SMART shows no issues on the drives themselves.

So in theory what could be causing an issue such as this with no errors being reported when the files are being written but immediately report an error when the ZFS pool is scrubbed?
 

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
Anecdotally, the files being reported seem to be large files. In this test case:

1.7G
14G
6.9G

Just some more info in case this triggers some thinking.
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
You may try to enable iSCSI checksums to make sure it is not caused by some undetected network packet corruption. Though it will cost you some CPU time. FreeNAS 11.0 should support CRC32 offload on recent Intel CPUs (may be not yours), which should make overhead less significant.
 

rs225

Guru
Joined
Jun 28, 2014
Messages
878
It would help if you posted the zpool status that shows the checksum errors for each vdev/drive.

You're probably looking at a disk controller, cable, or Norco/backplane issue. Check firmware version on your controller.
 

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
It would help if you posted the zpool status that shows the checksum errors for each vdev/drive.

You're probably looking at a disk controller, cable, or Norco/backplane issue. Check firmware version on your controller.

The disk controller is a LSI SAS 9202-16E Host Bus Adapter:

Code:
root@sanserver] ~# mpsutil show all

Adapter:

mps0 Adapter:

	  Board Name:

  Board Assembly:

		Chip Name: LSISAS2116

	Chip Revision:

	BIOS Revision: 7.39.02.00

Firmware Revision: 20.00.07.00

  Integrated RAID: no


PhyNum  CtlrHandle  DevHandle  Disabled  Speed   Min	Max	Device

0	   0001		0011	   N		 6.0	 1.5	6.0	SAS Initiator

1	   0002		0012	   N		 6.0	 1.5	6.0	SAS Initiator

2	   0003		0013	   N		 6.0	 1.5	6.0	SAS Initiator

3	   0004		0014	   N		 6.0	 1.5	6.0	SAS Initiator

4	   0005		0015	   N		 6.0	 1.5	6.0	SAS Initiator

5	   0006		0016	   N		 6.0	 1.5	6.0	SAS Initiator

6	   0007		0017	   N		 6.0	 1.5	6.0	SAS Initiator

7	   0008		0018	   N		 6.0	 1.5	6.0	SAS Initiator

8	   0009		0019	   N		 6.0	 1.5	6.0	SAS Initiator

9	   000a		001a	   N		 6.0	 1.5	6.0	SAS Initiator

10	  000b		001b	   N		 6.0	 1.5	6.0	SAS Initiator

11	  000c		001c	   N		 6.0	 1.5	6.0	SAS Initiator

12	  000d		001d	   N		 6.0	 1.5	6.0	SAS Initiator

13	  000e		001e	   N		 6.0	 1.5	6.0	SAS Initiator

14	  000f		001f	   N		 6.0	 1.5	6.0	SAS Initiator

15	  0010		0020	   N		 6.0	 1.5	6.0	SAS Initiator


Devices:

B____T	SAS Address	  Handle  Parent	Device		Speed Enc  Slot  Wdt

00   40   4433221100000000 0011	0001	  SATA Target   6.0   0001 03	1

00   38   4433221101000000 0012	0002	  SATA Target   6.0   0001 02	1

00   37   4433221102000000 0013	0003	  SATA Target   6.0   0001 01	1

00   39   4433221103000000 0014	0004	  SATA Target   6.0   0001 00	1

00   24   4433221104000000 0015	0005	  SATA Target   6.0   0001 07	1

00   36   4433221105000000 0016	0006	  SATA Target   6.0   0001 06	1

00   26   4433221106000000 0017	0007	  SATA Target   6.0   0001 05	1

00   27   4433221107000000 0018	0008	  SATA Target   6.0   0001 04	1

00   28   4433221108000000 0019	0009	  SATA Target   6.0   0001 11	1

00   34   4433221109000000 001a	000a	  SATA Target   6.0   0001 10	1

00   30   443322110a000000 001b	000b	  SATA Target   6.0   0001 09	1

00   31   443322110b000000 001c	000c	  SATA Target   6.0   0001 08	1

00   32   443322110c000000 001d	000d	  SATA Target   6.0   0001 15	1

00   33   443322110d000000 001e	000e	  SATA Target   6.0   0001 14	1

00   41   443322110e000000 001f	000f	  SATA Target   6.0   0001 13	1

00   35   443322110f000000 0020	0010	  SATA Target   6.0   0001 12	1


Enclosures:

Slots	  Logical ID	 SEPHandle  EncHandle	Type

  16	500605b002c8abe8			   0001	 Direct Attached SGPIO


Expanders:

NumPhys   SAS Address	 DevHandle   Parent  EncHandle  SAS Level


[root@sanserver] ~#

I have tried this with two different RAID10 volumes each with 4 mirrored disk pairs. Each of these pools use drives on different backplane boards.

I have another pool that is directly off the motherboard SATA ports that I can try. This would eliminate the disk controller, cable, or Norco/backplane from the equation as it would be using the onboard motherboard controller, different SATA cables, different drives, and the Norco/backplane.

So thinking about this, these ZFS volumes as seen on the FreeNAS server, see no errors at all. Since ZFS is the one providing the RAID10 support on the FreeNAS server, not a RAID adapter, then this means that ZFS is writing the same data on the mirrors in the pool. Otherwise ZFS on the FreeNAS server would be seeing checksum errors itself I would think.
 
Last edited by a moderator:

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
I tried using another pool using the 3 Toshiba 7200 6TB SATA 6Gbs/sec Hard Drives directly connected to the motherboard. The pool looks like:

Code:
[root@sanserver] ~# zpool status S0

  pool: S0

 state: ONLINE

  scan: scrub in progress since Tue Jun 13 13:21:22 2017

		96.8G scanned out of 361G at 223M/s, 0h20m to go

		0 repaired, 26.80% done

config:


	NAME											STATE	 READ WRITE CKSUM

	S0											  ONLINE	   0	 0	 0

	  raidz1-0									  ONLINE	   0	 0	 0

		gptid/7850cb65-0413-11e7-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/792d7b32-0413-11e7-ad35-00074305936a  ONLINE	   0	 0	 0

		gptid/7a83c4db-0413-11e7-ad35-00074305936a  ONLINE	   0	 0	 0


errors: No known data errors

[root@sanserver] ~# 


The zvol is "m3000data"

Code:
[root@sanserver] ~# zfs list -o name,type,available,used,volblocksize,volmode,sync

NAME												 TYPE		AVAIL   USED  VOLBLOCK  VOLMODE	  SYNC

D0												   filesystem   758G  1.02T		 -  default  standard

D0/D0vol											 volume	  1.66T  1.02T	   16K  default  standard

D1												   filesystem   758G  1.02T		 -  default  standard

D1/D1vol											 volume	  1.66T  1.02T	   16K  default  standard

M2M0												 filesystem  1.68T  82.5G		 -  default  standard

S0												   filesystem  7.44T  3.05T		 -  default  standard

S0/.system										   filesystem  7.44T   403M		 -  default  standard

S0/.system/configs-ea02119b0df4495ba64ec1dbdd61ed06  filesystem  7.44T   352K		 -  default  standard

S0/.system/cores									 filesystem  7.44T   117K		 -  default  standard

S0/.system/rrd-ea02119b0df4495ba64ec1dbdd61ed06	  filesystem  7.44T   117K		 -  default  standard

S0/.system/samba4									filesystem  7.44T   192K		 -  default  standard

S0/.system/syslog-ea02119b0df4495ba64ec1dbdd61ed06   filesystem  7.44T   384K		 -  default  standard

S0/m3000data										 volume	  10.2T  3.05T	   16K  default  standard

freenas-boot										 filesystem   224G   883M		 -  default  standard

freenas-boot/ROOT									filesystem   224G   875M		 -  default  standard

freenas-boot/ROOT/Initial-Install					filesystem   224G	 8K		 -  default  standard

freenas-boot/ROOT/default							filesystem   224G   875M		 -  default  standard

freenas-boot/grub									filesystem   224G  7.29M		 -  default  standard

[root@sanserver] ~# 



On the M3000 side, the ZFS pool looks like:

Code:
bash-3.2# zpool status -v sdata

  pool: sdata

 state: ONLINE

status: One or more devices has experienced an error resulting in data

		corruption.  Applications may be affected.

action: Restore the file in question if possible.  Otherwise restore the

		entire pool from backup.

  see: http://www.sun.com/msg/ZFS-8000-8A

 scan: scrub repaired 0 in 0h39m with 3 errors on Tue Jun 13 13:08:00 2017

config:


		NAME									 STATE	 READ WRITE CKSUM

		sdata									ONLINE	   0	 0	 3

		  c1t6589CFC000000B7BB31223F1B35E8F40d0  ONLINE	   0	 0	 6


errors: Permanent errors have been detected in the following files:


		/sdata/data/csemdb/seg0/c44b161.dat

		/sdata/data/csemdb/seg0/c447621.dat

		/sdata/data/csemdb/seg0/caff0.dat

bash-3.2#  


For the test, I created the ISCSI initiator on the M3000, created the ZFS pool, create the "data" filesystem, extracted about 582G of data to this filesystem and then immediately did a "zfs scrub sdata". The above is the result.

I think this can effectively rule out he Norco backplane, controller card, and cables since this test used the motherboard SATA controllers, separate set of cables and separate set of disks. The result is the same however.

There were 7162 files that make up the 582G data that was stored and 3 of the files are being reported as having checksum errors.

I am leaning towards thinking that this just does not work with "sync=standard".
 

Brett Bergquist

Dabbler
Joined
Jun 7, 2017
Messages
13
I got this working but would like some feedback why.

Things I tried:
  • I upgraded FreeNAS to FreeNAS 11 and retested with no success.
  • I setup FreeNAS ISCSI targets to be disk devices and not ZVOLs basically eliminating ZFS from the equation on the FreeNAS side. With 2 ISCSI targets creating a mirrored ZFS pool on the M3000 side, I would get errors when the pool was scrubbed but these were recoverable from the other device in the mirror.
  • I tried a Solaris VM running on an ESXi server to the same FreeNAS server. the ESXi server has an Intel 10G card. This worked which lead me to believe that it could work and maybe something to do with the Chelsio S320 10G in the M3000
  • I tried disabling the LSO on the Chelsio S320E 10G card on the M3000 as well as configuring the MTU to 1500 instead of 9000. Still errors.
At one point on the FreeNAS server, I saw this in the message log:

Code:
Jun 20 22:59:02 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): received PDU with CmdSN 8535941, while expected 8537982
Jun 20 22:59:02 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): received PDU with CmdSN 8537983, while expected 8537982; dropping connection
Jun 20 22:59:02 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): received PDU with CmdSN 8537984, while expected 8537982; dropping connection


So it looked like a protocol error occurred.

On a whim, on the M3000 initiator, I enabled data and header digests for the ISCSI target. I was able to transfer with no corruption reported from the pool when scrubbed.

I backed of and just enabled header digests and still was able to transfer with no corrupt from the pool reported when scrubbed.

As a test to confirm that the header digests were making the difference, I disabled the header digests and tried again with MTU = 8000, and LSO disabled on the Chelsio S320E card.

Code:
bash-3.2# ndd -get /dev/cxge0 \?
?							 (read only)
accept-jumbo				  (read and write)
hw-csum					   (read and write)
lso						   (read and write)
rx_pause					  (read and write)
tx_pause					  (read and write)
coalesce					  (read and write)
bash-3.2# ndd -get /dev/cxge0 accept-jumbo
1
bash-3.2# ndd -get /dev/cxge0 hw-csum
1
bash-3.2# ndd -get /dev/cxge0 lso
0
bash-3.2# ndd -get /dev/cxge0 rx_pause
1
bash-3.2# ndd -get /dev/cxge0 tx_pause
1
bash-3.2# ndd -get /dev/cxge0 coalesce
5
bash-3.2#


Immediately the M3000 side reported:

Code:
Jun 22 08:13:09 ct-m3000-global scsi: [ID 243001 kern.info] /scsi_vhci (scsi_vhci0):
Jun 22 08:13:09 ct-m3000-global		 /scsi_vhci/ssd@g6589cfc00000029aadcfeeaa310ae53b (ssd12): Command failed to complete (3) on path iscsi0/ssd@0000iqn.2005-10.org.freenas.ctl:m30000001,0
Jun 22 08:13:09 ct-m3000-global scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/ssd@g6589cfc00000029aadcfeeaa310ae53b (ssd12):
Jun 22 08:13:09 ct-m3000-global		 SCSI transport failed: reason 'tran_err': retrying command
Jun 22 08:13:22 ct-m3000-global scsi: [ID 243001 kern.info] /scsi_vhci (scsi_vhci0):
Jun 22 08:13:22 ct-m3000-global		 /scsi_vhci/ssd@g6589cfc00000029aadcfeeaa310ae53b (ssd12): Command failed to complete (3) on path iscsi0/ssd@0000iqn.2005-10.org.freenas.ctl:m30000001,0
...


and the FreeNAS side reported:

Code:
Jun 22 08:13:09 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): no ping reply (NOP-Out) after 5 seconds; dropping connection
Jun 22 08:13:09 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): waiting for CTL to terminate 6 tasks
Jun 22 08:13:09 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): tasks terminated
Jun 22 08:13:22 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): no ping reply (NOP-Out) after 5 seconds; dropping connection
Jun 22 08:13:22 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): waiting for CTL to terminate 9 tasks
Jun 22 08:13:22 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): tasks terminated
Jun 22 08:13:36 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240:
...


I actually had to reboot both the FreeNAS server and the M3000 to get this to come back up.

So to recap, the M3000 are directly connected to each other through a Chelsio S320E card with quality cable.

Here is the statistics from from the M3000 side using "netstat" . This is before I copied 585G of data to the ZFS pool backed by the ISCSI target

M3000 Before IP statistics

Code:
IPv4	ipForwarding		=	 2	 ipDefaultTTL		=   255
		ipInReceives		=72469839   ipInHdrErrors	   =	 0
		ipInAddrErrors	  =	 0	 ipInCksumErrs	   =	 0
		ipForwDatagrams	 =	 0	 ipForwProhibits	 =   180
		ipInUnknownProtos   =	 1	 ipInDiscards		=	 0
		ipInDelivers		=72469026   ipOutRequests	   =40016277
		ipOutDiscards	   =	 0	 ipOutNoRoutes	   =	 0
		ipReasmTimeout	  =	15	 ipReasmReqds		=	 0
		ipReasmOKs		  =	 0	 ipReasmFails		=	 0
		ipReasmDuplicates   =	 0	 ipReasmPartDups	 =	 0
		ipFragOKs		   =	 0	 ipFragFails		 =	 0
		ipFragCreates	   =	 0	 ipRoutingDiscards   =	 0
		tcpInErrs		   =	 0	 udpNoPorts		  =   752
		udpInCksumErrs	  =	 0	 udpInOverflows	  =	 0
		rawipInOverflows	=	 0	 ipsecInSucceeded	=   446
		ipsecInFailed	   =	 0	 ipInIPv6			=	 0
		ipOutIPv6		   =	 0	 ipOutSwitchIPv6	 =	 0


M3000 After IP statistics

Code:
IPv4	ipForwarding		=	 2	 ipDefaultTTL		=   255
		ipInReceives		=106913420  ipInHdrErrors	   =	 0
		ipInAddrErrors	  =	 0	 ipInCksumErrs	   =	 0
		ipForwDatagrams	 =	 0	 ipForwProhibits	 =   180
		ipInUnknownProtos   =	 1	 ipInDiscards		=	 0
		ipInDelivers		=106911636  ipOutRequests	   =70481324
		ipOutDiscards	   =	 0	 ipOutNoRoutes	   =	 0
		ipReasmTimeout	  =	15	 ipReasmReqds		=	 0
		ipReasmOKs		  =	 0	 ipReasmFails		=	 0
		ipReasmDuplicates   =	 0	 ipReasmPartDups	 =	 0
		ipFragOKs		   =	 0	 ipFragFails		 =	 0
		ipFragCreates	   =	 0	 ipRoutingDiscards   =	 0
		tcpInErrs		   =	 0	 udpNoPorts		  =  1723
		udpInCksumErrs	  =	 0	 udpInOverflows	  =	 0
		rawipInOverflows	=	 0	 ipsecInSucceeded	=   446
		ipsecInFailed	   =	 0	 ipInIPv6			=	 0
		ipOutIPv6		   =	 0	 ipOutSwitchIPv6	 =	 0


M3000 Before TCP statistics
Code:
TCP	 tcpRtoAlgorithm	 =	 4	 tcpRtoMin		   =   400
		tcpRtoMax		   = 60000	 tcpMaxConn		  =	-1
		tcpActiveOpens	  =	17	 tcpPassiveOpens	 =	 8
		tcpAttemptFails	 =	 7	 tcpEstabResets	  =	 2
		tcpCurrEstab		=	 5	 tcpOutSegs		  =40023845
		tcpOutDataSegs	  =4896582	tcpOutDataBytes	 =335910143
		tcpRetransSegs	  =	 1	 tcpRetransBytes	 =	 0
		tcpOutAck		   =35119484   tcpOutAckDelayed	=  6520
		tcpOutUrg		   =	 0	 tcpOutWinUpdate	 =   428
		tcpOutWinProbe	  =	 0	 tcpOutControl	   =	46
		tcpOutRsts		  =	 9	 tcpOutFastRetrans   =	 0
		tcpInSegs		   =72468715
		tcpInAckSegs		=4864542	tcpInAckBytes	   =335910151
		tcpInDupAck		 =	 8	 tcpInAckUnsent	  =	 0
		tcpInInorderSegs	=72443741   tcpInInorderBytes   =1086680933
		tcpInUnorderSegs	=	 0	 tcpInUnorderBytes   =	 0
		tcpInDupSegs		=	 0	 tcpInDupBytes	   =	 0
		tcpInPartDupSegs	=	 0	 tcpInPartDupBytes   =	 0
		tcpInPastWinSegs	=	 0	 tcpInPastWinBytes   =	 0
		tcpInWinProbe	   =	 0	 tcpInWinUpdate	  =	 0
		tcpInClosed		 =	 2	 tcpRttNoUpdate	  =  4584
		tcpRttUpdate		=4859947	tcpTimRetrans	   =	 0
		tcpTimRetransDrop   =	 0	 tcpTimKeepalive	 =	 0
		tcpTimKeepaliveProbe=	 0	 tcpTimKeepaliveDrop =	 0
		tcpListenDrop	   =	 0	 tcpListenDropQ0	 =	 0
		tcpHalfOpenDrop	 =	 0	 tcpOutSackRetrans   =	 0


M3000 After TCP Statistics

Code:
TCP	 tcpRtoAlgorithm	 =	 4	 tcpRtoMin		   =   400
		tcpRtoMax		   = 60000	 tcpMaxConn		  =	-1
		tcpActiveOpens	  =	19	 tcpPassiveOpens	 =	 9
		tcpAttemptFails	 =	 7	 tcpEstabResets	  =	 2
		tcpCurrEstab		=	 6	 tcpOutSegs		  =137559419
		tcpOutDataSegs	  =33682786   tcpOutDataBytes	 =2021111811
		tcpRetransSegs	  =	38	 tcpRetransBytes	 =331520
		tcpOutAck		   =36798482   tcpOutAckDelayed	= 12351
		tcpOutUrg		   =	 0	 tcpOutWinUpdate	 =   428
		tcpOutWinProbe	  =	 0	 tcpOutControl	   =	51
		tcpOutRsts		  =	11	 tcpOutFastRetrans   =	 0
		tcpInSegs		   =106911534
		tcpInAckSegs		=31017044   tcpInAckBytes	   =2020521269
		tcpInDupAck		 =	32	 tcpInAckUnsent	  =	 0
		tcpInInorderSegs	=81605515   tcpInInorderBytes   =1563304710
		tcpInUnorderSegs	=	 0	 tcpInUnorderBytes   =	 0
		tcpInDupSegs		=	86	 tcpInDupBytes	   =  4466
		tcpInPartDupSegs	=	 0	 tcpInPartDupBytes   =	 0
		tcpInPastWinSegs	=	 0	 tcpInPastWinBytes   =	 0
		tcpInWinProbe	   =	 0	 tcpInWinUpdate	  =	 0
		tcpInClosed		 =	 2	 tcpRttNoUpdate	  =20855360
		tcpRttUpdate		=10161671   tcpTimRetrans	   =	14
		tcpTimRetransDrop   =	 0	 tcpTimKeepalive	 =	 4
		tcpTimKeepaliveProbe=	 0	 tcpTimKeepaliveDrop =	 0
		tcpListenDrop	   =	 0	 tcpListenDropQ0	 =	 0
		tcpHalfOpenDrop	 =	 0	 tcpOutSackRetrans   =	 0


On the FreeNAS side

FreeNAS Before IP Statistics

Code:
ip:
		34733271 total packets received
		0 bad header checksums
		0 with size smaller than minimum
		0 with data size < data length
		0 with ip length > max ip packet size
		0 with header length < data size
		0 with data length < header length
		0 with bad options
		0 with incorrect version number
		0 fragments received
		0 fragments dropped (dup or out of space)
		0 fragments dropped after timeout
		0 packets reassembled ok
		34733269 packets for this host
		0 packets for unknown/unsupported protocol
		0 packets forwarded (0 packets fast forwarded)
		0 packets not forwardable
		11 packets received for unknown multicast group
		0 redirects sent
		34938942 packets sent from this host
		0 packets sent with fabricated ip header
		0 output packets dropped due to no bufs, etc.
		4 output packets discarded due to no route
		0 output datagrams fragmented
		0 fragments created
		0 datagrams that can't be fragmented
		0 tunneling packets that can't find gif
		0 datagrams with bad address in header


FreeNAS After IP Statistics

Code:
ip:
		63654535 total packets received
		0 bad header checksums
		0 with size smaller than minimum
		0 with data size < data length
		0 with ip length > max ip packet size
		0 with header length < data size
		0 with data length < header length
		0 with bad options
		0 with incorrect version number
		0 fragments received
		0 fragments dropped (dup or out of space)
		0 fragments dropped after timeout
		0 packets reassembled ok
		63654533 packets for this host
		0 packets for unknown/unsupported protocol
		0 packets forwarded (0 packets fast forwarded)
		0 packets not forwardable
		35 packets received for unknown multicast group
		0 redirects sent
		69443030 packets sent from this host
		0 packets sent with fabricated ip header
		0 output packets dropped due to no bufs, etc.
		4 output packets discarded due to no route
		0 output datagrams fragmented
		0 fragments created
		0 datagrams that can't be fragmented
		0 tunneling packets that can't find gif
		0 datagrams with bad address in header


FreeNAS Before TCP Statistics

Code:
tcp:
		34938758 packets sent
				34881862 data packets (632491612554 bytes)
				14 data packets (1545 bytes) retransmitted
				0 data packets unnecessarily retransmitted
				0 resends initiated by MTU discovery
				46304 ack-only packets (6036 delayed)
				0 URG only packets
				0 window probe packets
				2 window update packets
				10580 control packets
		34730712 packets received
				32472358 acks (for 632491627850 bytes)
				2716 duplicate acks
				0 acks for unsent data
				4900795 packets (350268867 bytes) received in-sequence
				77 completely duplicate packets (130 bytes)
				0 old duplicate packets
				0 packets with some dup. data (0 bytes duped)
				0 out-of-order packets (0 bytes)
				0 packets (0 bytes) of data after window
				0 window probes
				7766 window update packets
				61 packets received after close
				0 discarded for bad checksums
				0 discarded for bad header offset fields
				0 discarded because packet too short
				0 discarded due to memory problems
		5166 connection requests
		5351 connection accepts
		0 bad connection attempts
		0 listen queue overflows
		0 ignored RSTs in the windows
		10475 connections established (including accepts)
				10460 times used RTT from hostcache
				10460 times used RTT variance from hostcache
				1 time used slow-start threshold from hostcache
		10193 connections closed (including 77 drops)
				478 connections updated cached RTT on close
				479 connections updated cached RTT variance on close
				1 connection updated cached ssthresh on close
		42 embryonic connections dropped
		12596423 segments updated rtt (of 12584412 attempts)
		13 retransmit timeouts
				1 connection dropped by rexmit timeout
		0 persist timeouts
				0 connections dropped by persist timeout
		0 Connections (fin_wait_2) dropped because of timeout
		0 keepalive timeouts
				0 keepalive probes sent
				0 connections dropped by keepalive
		29784245 correct ACK header predictions
		2234820 correct data packet header predictions
		5351 syncache entries added
				0 retransmitted
				0 dupsyn
				0 dropped
				5351 completed
				0 bucket overflow
				0 cache overflow
				0 reset
				0 stale
				0 aborted
				0 badack
				0 unreach
				0 zone failures
		5351 cookies sent
		0 cookies received
		4 hostcache entries added
				0 bucket overflow
		0 SACK recovery episodes
		0 segment rexmits in SACK recovery episodes
		0 byte rexmits in SACK recovery episodes
		0 SACK options (SACK blocks) received
		0 SACK options (SACK blocks) sent
		0 SACK scoreboard overflow
		0 packets with ECN CE bit set
		9189 packets with ECN ECT(0) bit set
		0 packets with ECN ECT(1) bit set
		97 successful ECN handshakes
		0 times ECN reduced the congestion window
		0 packets with matching signature received
		0 packets with bad signature received
		0 times failed to make signature due to no SA
		0 times unexpected signature received
		0 times no signature provided by segment
TCP connection count by state:
		0 connections in CLOSED state
		10 connections in LISTEN state
		0 connections in SYN_SENT state
		0 connections in SYN_RCVD state
		16 connections in ESTABLISHED state
		0 connections in CLOSE_WAIT state
		0 connections in FIN_WAIT_1 state
		0 connections in CLOSING state
		0 connections in LAST_ACK state
		0 connections in FIN_WAIT_2 state
		470 connections in TIME_WAIT state


FreeNAS After TCP Statistics

Code:
tcp:
		69442123 packets sent
				44071864 data packets (633013769758 bytes)
				28 data packets (5913 bytes) retransmitted
				0 data packets unnecessarily retransmitted
				0 resends initiated by MTU discovery
				25330373 ack-only packets (13378 delayed)
				0 URG only packets
				0 window probe packets
				18432 window update packets
				21430 control packets
		63648080 packets received
				39431734 acks (for 633013799646 bytes)
				5093 duplicate acks
				0 acks for unsent data
				33664515 packets (629115436043 bytes) received in-sequence
				78 completely duplicate packets (130 bytes)
				0 old duplicate packets
				0 packets with some dup. data (0 bytes duped)
				0 out-of-order packets (0 bytes)
				0 packets (0 bytes) of data after window
				0 window probes
				15555 window update packets
				125 packets received after close
				0 discarded for bad checksums
				0 discarded for bad header offset fields
				0 discarded because packet too short
				0 discarded due to memory problems
		10466 connection requests
		10891 connection accepts
		0 bad connection attempts
		0 listen queue overflows
		0 ignored RSTs in the windows
		21315 connections established (including accepts)
				21298 times used RTT from hostcache
				21298 times used RTT variance from hostcache
				2 times used slow-start threshold from hostcache
		21561 connections closed (including 139 drops)
				848 connections updated cached RTT on close
				851 connections updated cached RTT variance on close
				3 connections updated cached ssthresh on close
		42 embryonic connections dropped
		15931180 segments updated rtt (of 15906685 attempts)
		27 retransmit timeouts
				1 connection dropped by rexmit timeout
		0 persist timeouts
				0 connections dropped by persist timeout
		0 Connections (fin_wait_2) dropped because of timeout
		1 keepalive timeout
				1 keepalive probe sent
				0 connections dropped by keepalive
		29893218 correct ACK header predictions
		24169053 correct data packet header predictions
		10891 syncache entries added
				0 retransmitted
				0 dupsyn
				0 dropped
				10891 completed
				0 bucket overflow
				0 cache overflow
				0 reset
				0 stale
				0 aborted
				0 badack
				0 unreach
				0 zone failures
		10891 cookies sent
		0 cookies received
		5 hostcache entries added
				0 bucket overflow
		0 SACK recovery episodes
		0 segment rexmits in SACK recovery episodes
		0 byte rexmits in SACK recovery episodes
		0 SACK options (SACK blocks) received
		0 SACK options (SACK blocks) sent
		0 SACK scoreboard overflow
		0 packets with ECN CE bit set
		22847 packets with ECN ECT(0) bit set
		0 packets with ECN ECT(1) bit set
		233 successful ECN handshakes
		0 times ECN reduced the congestion window
		0 packets with matching signature received
		0 packets with bad signature received
		0 times failed to make signature due to no SA
		0 times unexpected signature received
		0 times no signature provided by segment
TCP connection count by state:
		0 connections in CLOSED state
		10 connections in LISTEN state
		0 connections in SYN_SENT state
		0 connections in SYN_RCVD state
		4 connections in ESTABLISHED state
		0 connections in CLOSE_WAIT state
		0 connections in FIN_WAIT_1 state
		0 connections in CLOSING state
		0 connections in LAST_ACK state
		0 connections in FIN_WAIT_2 state
		2 connections in TIME_WAIT state


On the FreeNAS side, I saw this in the log after the transfer:

Code:
Jun 22 10:31:19 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): no ping reply (NOP-Out) after 5 seconds; dropping connection
Jun 22 10:31:19 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): waiting for CTL to terminate 5 tasks
Jun 22 10:31:19 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): tasks terminated
Jun 22 10:31:29 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): no ping reply (NOP-Out) after 5 seconds; dropping connection
Jun 22 10:31:29 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): waiting for CTL to terminate 3 tasks
Jun 22 10:31:29 freenas WARNING: 192.168.11.2 (iqn.1986-03.com.sun:01:000b5de240e4.4dadca1c): tasks terminated


On the M3000 side, I saw this in the log after the transfer:

Code:
Jun 22 10:31:19 ct-m3000-global scsi: [ID 243001 kern.info] /scsi_vhci (scsi_vhci0):
Jun 22 10:31:19 ct-m3000-global		 /scsi_vhci/ssd@g6589cfc00000029aadcfeeaa310ae53b (ssd12): Command failed to complete (3) on path iscsi0/ssd@0000iqn.2005-10.org.freenas.ctl:m30000001,0
Jun 22 10:31:19 ct-m3000-global scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/ssd@g6589cfc00000029aadcfeeaa310ae53b (ssd12):
Jun 22 10:31:19 ct-m3000-global		 SCSI transport failed: reason 'tran_err': retrying command
Jun 22 10:31:29 ct-m3000-global scsi: [ID 243001 kern.info] /scsi_vhci (scsi_vhci0):
Jun 22 10:31:29 ct-m3000-global		 /scsi_vhci/ssd@g6589cfc00000029aadcfeeaa310ae53b (ssd12): Command failed to complete (3) on path iscsi0/ssd@0000iqn.2005-10.org.freenas.ctl:m30000001,0



Running "zpool scrub" on the pool on the M3000, I see

Code:
bash-3.2# zpool status -v sanspace
  pool: sanspace
state: ONLINE
status: One or more devices has experienced an error resulting in data
		corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
		entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
scan: scrub repaired 0 in 0h31m with 11 errors on Thu Jun 22 11:20:15 2017
config:

		NAME									 STATE	 READ WRITE CKSUM
		sanspace								 ONLINE	   0	 0	11
		  c1t6589CFC00000029AADCFEEAA310AE53Bd0  ONLINE	   0	 0	22

errors: Permanent errors have been detected in the following files:

		/sanspace/data/csemdb/seg0/c44b181.dat
		/sanspace/data/csemdb/seg0/c44ec71.dat
		/sanspace/data/csemdb/seg0/c7790.dat
		/sanspace/data/csemdb/seg0/c82e0.dat
		/sanspace/data/csemdb/seg0/c84c0.dat
		/sanspace/data/csemdb/seg0/c44b131.dat
		/sanspace/data/csemdb/seg0/c4475b0.dat
		/sanspace/data/csemdb/seg0/c337c40.dat
		/sanspace/data/csemdb/seg0/c44ecb1.dat
		/sanspace/data/csemdb/seg0/ce8c0.dat
		/sanspace/data/csemdb/seg0/c5f30.dat
bash-3.2#



I am wondering how this is not being detected and corrected at the TCP level?

TCP is a reliable data stream and its TCP checksum probably should be catching data corruption errors and retransmitting.

Looking at the FreeNAS TCP statistics, there are very few duplicate packets, duplicate acks, and no out of order packets received. On the transmit side, there are very few retransmitted packets as well.

Looking at the M3000 TCP statistics, again there are very few duplicate packets, duplicate acks, and no out of order packets. On the transmit side again, there are very few retransmitted packets as well.

I think pretty much proves that a ISCSI protocol level corruption error is happening.

Any thoughts?
 
Status
Not open for further replies.
Top