> "Tom" == Tom Yan writes:
>> Many drives from different vendors were affected by this. So we'd
>> have to make multi block payloads an explicit opt-in like we did for
>> discard_zeroes_data. However, given that "big" discards are mainly
>> done synchronously when creating filesystems, I am n
On 11 August 2016 at 09:47, Martin K. Petersen
wrote:
>
> Tom> so we can at most allow only a 2-block (well, or 3-block) payload.
>
> We tried turning on multi block payloads and it was a massive disaster.
> Many drives reported that they supported 8 block payloads but actually
> didn't. Instead o
On 11 August 2016 at 02:29, Shaun Tancheff 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
> "Tom" == Tom Yan writes:
Tom> Well that is actually the minimum. Modern SSDs often support more
Tom> than one-block payload (e.g. 8, 16...). It's just our SCSI disk
Tom> driver statically limit it to the minimum. Though it allows only
Tom> 0x / 512 = 8388607 (SD_MAX_WS16_BLOCKS) bl
> "Shaun" == Shaun Tancheff 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
On Wed, Aug 10, 2016 at 6:30 AM, Tom Yan wrote:
> On 10 August 2016 at 14:31, Tom Yan wrote:
>> I don't really know about SCT Write Same but there is one concern I
>> could I think of.
>>
>> libata's SATL would report a maximum write same length base on the
>> number of sectors a one-block TRIM p
On 10 August 2016 at 14:31, Tom Yan wrote:
> I don't really know about SCT Write Same but there is one concern I
> could I think of.
>
> libata's SATL would report a maximum write same length base on the
> number of sectors a one-block TRIM payload can describe at most, which
> is 65535 * 64 = 419
I don't really know about SCT Write Same but there is one concern I
could I think of.
libata's SATL would report a maximum write same length base on the
number of sectors a one-block TRIM payload can describe at most, which
is 65535 * 64 = 4194240 (see ata_scsiop_inq_b0 in libata-scsi.c). If
the d
On 10 August 2016 at 14:34, Shaun Tancheff wrote:
>
> You are correct in that we can advertise the larger limit in
> ata_scsi_dev_config() when only SCT write same is supported
> rather than fall back to WS10.
ata_scsi_dev_config()? Not sure if I follow. We should only need to
report Maximum Writ
On Wed, Aug 10, 2016 at 11:50 AM, Tom Yan wrote:
> On 10 August 2016 at 14:34, Shaun Tancheff wrote:
>>
>> You are correct in that we can advertise the larger limit in
>> ata_scsi_dev_config() when only SCT write same is supported
>> rather than fall back to WS10.
>
> ata_scsi_dev_config()? Not s
SATA drives may support write same via SCT. This is useful
for setting the drive contents to a specific pattern (0's).
Translate a SCSI WRITE SAME command to be either a DSM TRIM command or
an SCT Write Same command.
Based on the UNMAP flag:
- When set translate to DSM TRIM
- When not set tra
11 matches
Mail list logo
