On Thu, Oct 26, 2017 at 01:01:29PM -0500, Eric Sandeen wrote: > On 10/26/17 12:49 PM, Eric Sandeen wrote: > > Yeah, lots of devices are unhappy with large discards. And yeah, in the > > end I think this papers over a kernel and/or hardware problem. > > > > But sometimes we do that, if only to keep things working reasonably > > well with older kernels or hardware that'll never get fixed... > > > > (TBH sometimes I regret putting mkfs-time discard in by default in the > > first place.) > > I think I left this on a too-positive note. It seems pretty clear that there > is no way to fix all of userspace to not issue "too big" discards, when > "too big" isn't even well-defined, or specified by anything at all. Yeah, I totally get this proposal is just a bandaid, and other user space programs may suffer when used with devices behaving this way. XFS is just very popular, so it's frequently reported as problematic against large capacity devices. > I'm not wise in the ways of queueing and throttling, but from my naiive > perspective, it seems like something to be fixed in the kernel, or if it > can't, export some new "maximum discard request size" which can be trusted? The problem isn't really that a discard sent to the device was "too big". It's that "too many" are issued at the same time, and there isn't a way for a driver to limit the number of outstanding discards without affecting read/write. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
