From: Keith Busch <keith.busch@intel.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfsprogs: Issue smaller discards at mkfs
Date: Thu, 26 Oct 2017 12:32:17 -0600 [thread overview]
Message-ID: <20171026183216.GA27317@localhost.localdomain> (raw)
In-Reply-To: <0d50ca3b-0b27-8ac1-c102-9ea656f3f926@sandeen.net>
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.
next prev parent reply other threads:[~2017-10-26 18:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 14:41 [PATCH] xfsprogs: Issue smaller discards at mkfs Keith Busch
2017-10-26 16:25 ` Darrick J. Wong
2017-10-26 17:49 ` Eric Sandeen
2017-10-26 18:01 ` Eric Sandeen
2017-10-26 18:32 ` Keith Busch [this message]
2017-10-26 19:59 ` Darrick J. Wong
2017-10-26 21:24 ` Keith Busch
2017-10-26 22:24 ` Dave Chinner
2017-10-26 23:09 ` Keith Busch
2017-10-26 18:00 ` Keith Busch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171026183216.GA27317@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.