Re: [PATCH 1/2] mkfs: Break block discard into chunks of 2 GB

[Eric Sandeen <sandeen@sandeen.net>]

On 11/22/19 3:30 PM, Eric Sandeen wrote:
> On 11/22/19 3:10 PM, Eric Sandeen wrote:
>> On 11/21/19 5:18 PM, Dave Chinner wrote:
>>> On Thu, Nov 21, 2019 at 10:44:44PM +0100, Pavel Reichl wrote:
>>>> Signed-off-by: Pavel Reichl <preichl@redhat.com>
>>>> ---
>>>
>>> This is mixing an explanation about why the change is being made
>>> and what was considered when making decisions about the change.
>>>
>>> e.g. my first questions on looking at the patch were:
>>>
>>> 	- why do we need to break up the discards into 2GB chunks?
>>> 	- why 2GB?
>>> 	- why not use libblkid to query the maximum discard size
>>> 	  and use that as the step size instead?
>>
>> Just wondering, can we trust that to be reasonably performant?
>> (the whole motivation here is for hardware that takes inordinately
>> long to do discard, I wonder if we can count on such hardware to
>> properly fill out this info....)
> 
> Looking at the docs in kernel/Documentation/block/queue-sysfs.rst:
> 
> discard_max_hw_bytes (RO)
> -------------------------
> Devices that support discard functionality may have internal limits on
> the number of bytes that can be trimmed or unmapped in a single operation.
> The discard_max_bytes parameter is set by the device driver to the maximum
> number of bytes that can be discarded in a single operation. Discard
> requests issued to the device must not exceed this limit. A discard_max_bytes
> value of 0 means that the device does not support discard functionality.
> 
> discard_max_bytes (RW)
> ----------------------
> While discard_max_hw_bytes is the hardware limit for the device, this
> setting is the software limit. Some devices exhibit large latencies when
> large discards are issued, setting this value lower will make Linux issue
> smaller discards and potentially help reduce latencies induced by large
> discard operations.
> 
> it seems like a strong suggestion that the discard_max_hw_bytes value may
> still be problematic, and discard_max_bytes can be hand-tuned to something
> smaller if it's a problem.  To me that indicates that discard_max_hw_bytes
> probably can't be trusted to be performant, and presumably discard_max_bytes
> won't be either in that case unless it's been hand-tuned by the admin?

Lukas, Jeff Moyer reminded me that you did a lot of investigation into this
behavior a while back.  Can you shed light on this, particularly how you
chose 2G as the discard granularity for mke2fs?

Thanks,
-Eric