Re: [PATCH v5 2/2] Add support for SCT Write Same

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Shaun" == Shaun Tancheff <shaun.tancheff@xxxxxxxxxxx> writes:

Shaun,

Shaun> You are correct in that we can advertise the larger limit in
Shaun> ata_scsi_dev_config() when only SCT write same is supported
Shaun> rather than fall back to WS10.

I deliberately capped WRITE SAME to 64K blocks unless otherwise reported
by the device because:

        a) Several older drives supported the WRITE SAME(16) command but
        ignored the upper bytes of the transfer length effectively
        turning it into a WRITE SAME(10).

        b) 64K blocks was the sweet spot for older drives as well, a
        size commonly used by RAID array firmwares that were the only
        commonplace users of the WRITE SAME family.

Shaun> I really am not sure what would be considered the correct
Shaun> solution though. I believe that the WRITE SAME defaults are
Shaun> currently being chosen around physical limits.

Lacking a solid reporting facility in the spec, I suggest you just leave
it unset and let the SCSI defaults apply.

Shaun> I think we can also bump the command timeout for WRITE SAME?

The default WRITE SAME timeout is 120s.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux