There's comment about `rq->__data_len` in sd.c (and blkdev.h, definition of struct `request`). Apparently it is "internal only" (in terms of the kernel).
As for `cmd->transfersize`, it's probably talking about the CDB itself. Although different commands have CDB of various lengths (much shorter than 512-byte), but I guess when the actual command is sent to the device, we will still transfer it in a full logical block for some reason. Anyway these will not have anything to do with how we form the TRIM payload. The SATL simply read the LBA (starting offset) and NUMBER OF BLOCK (to TRIM) field in the CDB and pack ranges according to that. All we care is the actual TRIM limit of the ATA device (and conservative concern on bogus ones). On 23 August 2016 at 08:42, Shaun Tancheff <shaun.tanch...@seagate.com> wrote: > On Tue, Aug 23, 2016 at 2:53 AM, Tom Yan <tom.t...@gmail.com> wrote: >> On 23 August 2016 at 06:20, Shaun Tancheff <shaun.tanch...@seagate.com> >> wrote: >>> On Tue, Aug 23, 2016 at 12:26 AM, Tom Yan <tom.t...@gmail.com> wrote: >>> >>>> It is always 1 merely because we prefer sticking to that. Say we want >>>> to enable multi-block payload now, it won't be 1 anymore. >>> >>> Sorry, I though that DSM TRIM is using 512 bytes here because >>> WRITE_SAME_16 has a payload of a single logical sector. >> >> Nope, SCSI Write Same commands does not have payload (or in SCSI >> terms, parameter list / data-out buffer). > > Hmm. Not sure about T10, but that's not how I read > sd_setup_write_same_cmnd(), it always setups up a transfer of > sector_size for scsi_init_io(). > > As I understand things, this is how the cmd's sglist is populated and why > this should be using sg_copy_from_buffer() rather than open coding > to the page. > -- > Shaun Tancheff
