[Bug 204642] 10.2 iSCSI connected initiator to a 10.1 iSCSI Target generates excessive UNMAP/TRIM commands, system unresponsive.

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204642

            Bug ID: 204642
           Summary: 10.2 iSCSI connected initiator to a 10.1 iSCSI Target
                    generates excessive UNMAP/TRIM commands, system
                    unresponsive.
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: misc
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: chris at acsi.ca

A FreeBSD 10.2-p7 RELEASE machine connected via CAM iSCSI Initiator to a
10.1p24 RELEASE iSCSI file-based target, on a zpool generates a crazy amount of
TRIM commands, locking the system. 

This is a gstat -d on the 10.2 Initiator, once the zpools are mounted, and just
a basic bit of activity is started (simple file write, etc - no real load)

dT: 12.546s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d  
%busy Name
    0      3      0      0    0.0      3     46   58.3      0      0    0.0   
4.2| da0
    0      0      0      0    0.0      0      0    0.0      0      0    0.0   
0.0| da0p1
    0      0      0      0    0.0      0      0    0.0      0      0    0.0   
0.0| da0p2
    0      3      0      0    0.0      3     46   58.3      0      0    0.0   
4.2| da0p3
    0 333485      0      0    0.0      0      0    0.0 333485      0    0.0  
48.0| da1
    0 306605      0      0    0.0      0      0    0.0 306605      0    0.0  
47.7| da2

Notice the huge number of deletes per second. 

The iSCSI Target doesn't seem to be doing anything, so I suspect these are
internally dying/retrying. They don't seem to show up in the sysctl:

# sysctl -a | grep trim
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 10000
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_min_active: 1
vfs.zfs.vdev.trim_on_init: 1
kstat.zfs.misc.zio_trim.failed: 0
kstat.zfs.misc.zio_trim.unsupported: 110
kstat.zfs.misc.zio_trim.success: 11
kstat.zfs.misc.zio_trim.bytes: 118784

I do notice that the delete_method is now switched to 'DISABLE'. It originally
was 'UNMAP' after boot, and before the zpools had activity. 

# sysctl -a | grep cam.da
kern.cam.da.2.minimum_cmd_size: 6
kern.cam.da.2.delete_max: 0
kern.cam.da.2.delete_method: DISABLE
kern.cam.da.1.error_inject: 0
kern.cam.da.1.sort_io_queue: 0
kern.cam.da.1.minimum_cmd_size: 6
kern.cam.da.1.delete_max: 0
kern.cam.da.1.delete_method: DISABLE
kern.cam.da.0.error_inject: 0
kern.cam.da.0.sort_io_queue: -1
kern.cam.da.0.minimum_cmd_size: 6
kern.cam.da.0.delete_max: 131072
kern.cam.da.0.delete_method: NONE



For reference, here is the /etc/ctl.conf on the 10.1 iSCSI Target:


portal-group pg0 {
        discovery-auth-group no-authentication
        listen 0.0.0.0
        listen [::]
}

        lun 0 {
                path /pool92/iscsi/iscsi.zvol
                blocksize 4K
                size 5T
                option unmap "on"
                option scsiname "pool92"
                option vendor "pool92"
                option insecure_tpc "on"
        }
}


target iqn.iscsi1.zvol {
        auth-group no-authentication
        portal-group pg0

        lun 0 {
                path /pool92_1/iscsi/iscsi.zvol
                blocksize 4K
                size 5T
                option unmap "on"
                option scsiname "pool92_1"
                option vendor "pool92_1"
                option insecure_tpc "on"
        }
}

Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.