On Sat, Mar 09, 2024 at 01:33:04PM -0500, Mike Snitzer wrote: > That 2015 commit (0034af036554) was really ham-handed, not sure how > I've remained unaware of this duality (with soft and hard discard > limits) until now BUT there is quite a bit of DM code that only > concerns itself with max_discard_sectors and discard_granularity. Yes. > Anyway, I'm not quite sure what you're referring to, only code that is > still setting max_discard_sectors is drivers/md/dm.c:disable_discard I mean all the places that I've updated to set max_discard_sectors really should be setting max_hw_discard_sectors. The rutime- disabling of discard/write_zeroes/secure_discard on failure will get new helpers one the atomic queue limits conversion is finished. > > > This fixes a regression where dm bio poison v1 warns about exceeding > > the discard bio size when running xfstests generic/500. > > Meaning max_discard_sectors > max_hw_discard_sectors? What changed to > expose this? queue_limits_set now always recalculates max_discard_sectors from max_hw_discard_sectors and max_user_discard_sectors. So if a driver sets max_discard_sectors but not max_hw_discard_sectors it will simply be overriden.
