>>>>> "tom" == tom ty89 <tom.ty89@xxxxxxxxx> writes: Tom, tom> [root@localhost ~]# sg_opcodes /dev/sdb > /dev/null Report tom> supported operation codes: Illegal request, invalid opcode tom> [root@localhost ~]# sg_vpd -p bl /dev/sdb | grep 'write same' tom> Maximum write same length: 0x0 blocks "A MAXIMUM WRITE SAME LENGTH field set to zero indicates that the device server does not report a limit on the number of logical blocks that it allows to be unmapped or written in a single WRITE SAME command." I.e. that parameter says nothing about whether WRITE SAME is supported or not. tom> [root@localhost ~]# cat /sys/block/sdb/queue/write_same_max_bytes tom> 33553920 That's correct behavior. Unless otherwise noted we default to issuing 32 MB WRITE SAME commands and will subsequently turn it off if the drive returns a failure. WRITE SAME support on storage devices predates RSOC, most of the common VPD pages, etc. So there is no reliable value we can key off of to determine whether a drive supports the command. And because a block count of 0 is interpreted as "the entire device" we can't issue a non-destructive WRITE SAME to determine whether device supports it or not. Consequently we are stuck with assuming it works unless RSOC is supported or the device sits behind a SATL. Do you have a particular drive that is causing problems? We could quirk it or add additional heuristics in addition to the ATA Information VPD. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
