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. -- 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
