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

[Tom Yan]

On 11 August 2016 at 02:29, Shaun Tancheff <shaun.tancheff@xxxxxxxxxxx> wrote:
>>
>> You are talking about an AF 4Kn drive I suppose? For a 512e drive it
>> should be only ~2G.
>
> I stand corrected. Since all the kernel math is 512 byte sectors you are
> absolutely correct and this isn't an issue at all.
>
> We should report SD_MAX_WS16_BLOCKS when only SCT
> is available and 4194240 when TRIM is available.

Why would you come up with such decision/conclusion? I thought
SD_MAX_WS16_BLOCKS could even be too big for 512e drive (~4G per WRITE
SAME command)?

If 4194240 (~2G per command) isn't too big for SCT Write Same, then we
shoud probably stick with it in both cases (when only SCT Write Same
is available / when TRIM is also available) to maintain consistency.

Also Maximum Write Same Length should be multiplied by the actual
logical sector size of the drive, which would be 4096 in the case of
4Kn drives. (If the kernel isn't doing that, it's simply a bug.)

Therefore, if I haven't missed anything, we'll need to divide
ATA_MAX_TRIM_RNUM by (logical sector size / 512) anyway, otherwise
discard_max_bytes and write_same_max_bytes would overflow with 4Kn
drive (i.e. Maximum Write Same Length needs to be <= 0xffffffff /
4096). 4Kn SSDs may not be a thing on the market yet, but apparently
it's a different story for traditional HDDs, and SCT Write Same isn't
only available on SSDs. The division should not change the current
behaviour on drives with 512-byte logical sectors.

I'll be sending a patch on that.