linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Pavel Reichl <preichl@redhat.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/2] mkfs: Break block discard into chunks of 2 GB
Date: Tue, 26 Nov 2019 14:53:23 -0600	[thread overview]
Message-ID: <1e0946c2-3129-8c03-0d71-de84a925288a@sandeen.net> (raw)
In-Reply-To: <20191121214445.282160-2-preichl@redhat.com>

On 11/21/19 3:44 PM, Pavel Reichl wrote:
> Signed-off-by: Pavel Reichl <preichl@redhat.com>
> ---
>  mkfs/xfs_mkfs.c | 32 +++++++++++++++++++++++++-------
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> index 18338a61..a02d6f66 100644
> --- a/mkfs/xfs_mkfs.c
> +++ b/mkfs/xfs_mkfs.c
> @@ -1242,15 +1242,33 @@ done:
>  static void
>  discard_blocks(dev_t dev, uint64_t nsectors)
>  {
> -	int fd;
> +	int		fd;
> +	uint64_t	offset		= 0;
> +	/* Maximal chunk of bytes to discard is 2GB */
> +	const uint64_t	step		= (uint64_t)2<<30;

Regarding the discard step size, I would like to just see us keep 2G -
I see problems with the alternate suggestions proposed in the
threads on this patch review:

1) query block device for maximal discard size
-> block device folks I've talked to (Jeff Moyer in particular) stated
   that many devices are known for putting a huge value in here, and then
   taking far, far too long to process that size request.  In short,
   maximum size != fast.

2) discard one AG size at a time
-> this can be up to 1T, which puts us right back at our problem of large,
   slow discards.  And in particular, AG size has no relation at all to a
   device's discard behavior.  (further complicating this, we don't have
   this geometry available anywhere in the current chain of calls to the
   discard ioctl.)

Lukas did an investigation of discard behaviors (though it was some time
ago https://sourceforge.net/projects/test-discard/) and arrived at 2G as
a reasonable size after testing many different devices - I've not seen any
complaints from mke2fs users about problems doing discards in 2G chunks.

So I think just picking a fixed 2G size is the best plan for now.

(one nitpick, I'd fix the comment above to not say "Maximal" because that
sounds like some hard limit imposed by something other than the code; I'd
just say "Discard the device 2G at a time" or something like that.)

A comment above the loop explaining in more detail that we iterate in
step sizes so that the utility can be interrupted would probably be
helpful.

Thanks,
-Eric

  parent reply	other threads:[~2019-11-26 20:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-21 21:44 [PATCH 0/2] mkfs: inform during block discarding Pavel Reichl
2019-11-21 21:44 ` [PATCH 1/2] mkfs: Break block discard into chunks of 2 GB Pavel Reichl
2019-11-21 21:55   ` Darrick J. Wong
2019-11-22 14:46     ` Pavel Reichl
2019-11-22 21:07     ` Eric Sandeen
2019-11-21 23:18   ` Dave Chinner
2019-11-22 15:38     ` Darrick J. Wong
2019-11-22 15:59       ` Pavel Reichl
2019-11-22 21:00         ` Dave Chinner
2019-11-22 16:09     ` Pavel Reichl
2019-11-22 21:10     ` Eric Sandeen
2019-11-22 21:30       ` Eric Sandeen
2019-11-26 19:40         ` Eric Sandeen
2019-11-26 20:53   ` Eric Sandeen [this message]
2019-11-21 21:44 ` [PATCH 2/2] mkfs: Show progress during block discard Pavel Reichl
2019-11-21 21:59   ` Darrick J. Wong
2019-11-22 16:27     ` Pavel Reichl
2019-11-22 16:31       ` Darrick J. Wong
2019-11-21 23:41   ` Dave Chinner
2019-11-22 16:43     ` Pavel Reichl
2019-11-22 21:11       ` Dave Chinner
2019-11-22 21:19       ` Eric Sandeen

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=1e0946c2-3129-8c03-0d71-de84a925288a@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=linux-xfs@vger.kernel.org \
    --cc=preichl@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).