On Tue, 2012-11-06 at 21:06 +0000, Prantis, Kelsey wrote: > Hello, Hi Kelsey, > I was hoping perhaps you guys might be able to help me figure out a new problem I am having with doing I/o on my targets: > > On my initiators, I am receiving these error messages in /var/log/messages > > Nov 6 20:15:38 hydra-2-ss-storage-appliance-1 kernel: sd 8:0:0:0: [sde] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > Nov 6 20:15:38 hydra-2-ss-storage-appliance-1 kernel: sd 8:0:0:0: [sde] Sense Key : Illegal Request [current] > Nov 6 20:15:38 hydra-2-ss-storage-appliance-1 kernel: sd 8:0:0:0: [sde] Add. Sense: Invalid field in cdb > Nov 6 20:15:38 hydra-2-ss-storage-appliance-1 kernel: sd 8:0:0:0: [sde] CDB: Write(10): 2a 00 00 02 dd 18 00 40 00 00 > > And over on my target server I am getting debug messages like these in my dmesg: > > [80076.570102] SCSI OP 2ah with too big sectors 10408 exceeds fabric_max_sectors: 8192 > [80076.598875] SCSI OP 2ah with too big sectors 16384 exceeds fabric_max_sectors: 8192 > [80079.416060] SCSI OP 2ah with too big sectors 16384 exceeds fabric_max_sectors: 8192 > [80079.425274] SCSI OP 2ah with too big sectors 16384 exceeds fabric_max_sectors: 8192 > [80079.432819] SCSI OP 2ah with too big sectors 16384 exceeds fabric_max_sectors: 8192 > [80079.439683] SCSI OP 2ah with too big sectors 8200 exceeds fabric_max_sectors: 8192 > > This is the same setup I've described before, a 3.6.3-1.fc17 target server, and el6 initiators. > So at this point it's safe to bump these default+max values of fabric_max_sectors for IBLOCK + RAMDISK_MCP backends. However, FILEIO will start to have problems here with > fabric_max_sectors=8192 payload size when the largish contiguous memory allocations for struct iovec with vfs_[read,write]v() ops start to fail. Here a quick target patch that should get you running with IBLOCK and RAMDISK_MCP backends: diff --git a/include/target/target_core_base.h b/include/target/target_core_base.h index 5350f6e..26d9db9 100644 --- a/include/target/target_core_base.h +++ b/include/target/target_core_base.h @@ -72,7 +72,7 @@ /* Default unmap_granularity_alignment */ #define DA_UNMAP_GRANULARITY_ALIGNMENT_DEFAULT 0 /* Default max transfer length */ -#define DA_FABRIC_MAX_SECTORS 8192 +#define DA_FABRIC_MAX_SECTORS 16384 /* Emulation for Direct Page Out */ #define DA_EMULATE_DPO 0 /* Emulation for Forced Unit Access WRITEs */ @@ -97,7 +97,7 @@ /* Enforce SCSI Initiator Port TransportID with 'ISID' for PR */ #define DA_ENFORCE_PR_ISIDS 1 #define DA_STATUS_MAX_SECTORS_MIN 16 -#define DA_STATUS_MAX_SECTORS_MAX 8192 +#define DA_STATUS_MAX_SECTORS_MAX 32768 /* By default don't report non-rotating (solid state) medium */ #define DA_IS_NONROT 0 /* Queue Algorithm Modifier default for restricted reordering in control mode page */ -- but will likely end up being a special case for FILEIO that we have to issue multiple I/Os in the backend to handle the large request. That said, I'm going to hold off merging these new defaults for the moment until that part can be sorted out with FILEIO. (hch CC'ed) Also, another option in the short term to get something work would be to reduce the max_sectors_kb on the iSCSI initiator LLD side to 8192 (or smaller) to prevent the large CDB payloads from being generated on the client side. (mnc + hare CC'ed) Thanks for reporting! --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
