Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1460134 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 2/2] Add support for SCT Write Same "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-08-11 03:50 +0200
    Re: [PATCH v5 2/2] Add support for SCT Write Same Tom Yan <tom.ty89@gmail.com> - 2016-08-11 10:50 +0200
      Re: [PATCH v5 2/2] Add support for SCT Write Same "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-08-12 03:20 +0200

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

>>>>> "Tom" == Tom Yan <tom.ty89@gmail.com> 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> 0xffffffff / 512 = 8388607 (SD_MAX_WS16_BLOCKS) blocks per WRITE
Tom> SAME (16) command anyway,

Yes, because that's the biggest command we can express in the block
layer.

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 of playing the blacklist game we capped it at a single
sector.

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 not sure there is any real
benefit to this.

-- 
Martin K. Petersen	Oracle Linux Engineering

[toc] | [next] | [standalone]

#1460276

On 11 August 2016 at 09:47, Martin K. Petersen
<martin.petersen@oracle.com> 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 of playing the blacklist game we capped it at a single
> sector.

I don't know, apparently Windows does multi block payloads though (at
least that's how it advertise on the simulated VPD).

What I meant was it will not make a big difference in our case anyway.
Given the 32-bit representation limitation, we could be at best using
a full 2-block payload. So let's not do 2 but 1? Fine :P

>
> 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 not sure there is any real
> benefit to this.
>

Probably. Perhaps it could make a difference upon deletion of some
really big files (though the logical sectors used may not be
continuous anyway).

> --
> Martin K. Petersen      Oracle Linux Engineering

[toc] | [prev] | [next] | [standalone]

#1460887

>>>>> "Tom" == Tom Yan <tom.ty89@gmail.com> 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 not sure there is
>> any real benefit to this.

Tom> Probably. Perhaps it could make a difference upon deletion of some
Tom> really big files (though the logical sectors used may not be
Tom> continuous anyway).

Nope. And you've got the bio size limit getting in the way as well.

-- 
Martin K. Petersen	Oracle Linux Engineering

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web