Hi Jens, I saw in the v2 of your original patchset that made max discard rw, you were going to set a 64M default, but Mike mentioned some issues it might present in dm, so you said you would come back to it later and decide on a default max [1]. In the link that Ming provided [2], the general consensus was that the hw manufacturers should do what they say; they've sold this function as fast, so they should make it fast. But unfortunately, from what I've read, it still seems there are very few, if any, devices that can truly handle a 2TiB discard well. Of course, I don't have any insight into the hw manufacturers intentions, but in my opinion, we shouldn't be keeping problematic kernel limits based on a selling point by the hw manufacturers. So, the thought (after bugging Ming offline) is we could take one of the below approaches: 1) Set a 64M limit as you've suggested in the past. It seems more prudent to tune the value upward for the few devices that can actually handle a 2TiB discard rather than tune downward for the large majority. 2) Create a udev rule to go into RHEL that would set 64M as we still steadily see support cases where max discard needs to be tuned downward. In either case, I suppose we'd have to figure a way to not impact dm. Maybe we could do that with a driver setting or udev rule? Jens and Mike, Do you guys have any thoughts on this? Asking here instead of RH bug (2160828) since Jens said he wanted to come back to this issue later in the thread mentioned. Thanks for the continued assistance. [1] https://lkml.org/lkml/2015/7/15/859 [2] https://lwn.net/Articles/787272/ On Mon, Jun 12, 2023 at 9:37 PM Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > 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 >
