On Fri, Jun 09, 2023 at 02:08:05PM -0400, John Pittman wrote: > Some drive manufacturers export a very large supported max discard size. Most of devices exports very large max discard size, and it shouldn't be just some. > However, when the operating system sends I/O of the max size to the > device, extreme I/O latency can often be encountered. Since hardware It often depends on drive internal state. > does not provide an optimal discard value in addition to the max, and > there is no way to foreshadow how well a drive handles the large size, > take the method from max_sectors setting, and use BLK_DEF_MAX_SECTORS to > set a more reasonable default discard max. This should avoid the extreme > latency while still allowing the user to increase the value for specific > needs. As Martin and Chaitanya mentioned, reducing max discard size to level of BLK_DEF_MAX_SECTORS won't be one ideal approach, and shouldn't be accepted, since discarding command is supposed to be cheap from device viewpoint, such as, SSD FW usually just marks the LBA ranges as invalid for handling discard. However, how well discard performs may depend on SSD internal, such as if GC is in-progress. And it might be one more generic issue for SSD, and it was discussed several times, such as "Issues around discard" in lsfmm2019: https://lwn.net/Articles/787272/ BTW, blk-wbt actually throttles discard, but it is just in queue depth level. If max discard size is too big, single big discard request still may cause device irresponsive. Thanks, Ming
