linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>, Pavel Reichl <preichl@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/2] mkfs: Break block discard into chunks of 2 GB
Date: Fri, 22 Nov 2019 15:10:26 -0600	[thread overview]
Message-ID: <b2bc2dea-575b-959a-0025-d5d20d733a55@sandeen.net> (raw)
In-Reply-To: <20191121231838.GH4614@dread.disaster.area>

On 11/21/19 5:18 PM, Dave Chinner wrote:
> On Thu, Nov 21, 2019 at 10:44:44PM +0100, Pavel Reichl wrote:
>> Signed-off-by: Pavel Reichl <preichl@redhat.com>
>> ---
> 
> This is mixing an explanation about why the change is being made
> and what was considered when making decisions about the change.
> 
> e.g. my first questions on looking at the patch were:
> 
> 	- why do we need to break up the discards into 2GB chunks?
> 	- why 2GB?
> 	- why not use libblkid to query the maximum discard size
> 	  and use that as the step size instead?

Just wondering, can we trust that to be reasonably performant?
(the whole motivation here is for hardware that takes inordinately
long to do discard, I wonder if we can count on such hardware to
properly fill out this info....)

> 	- is there any performance impact from breaking up large
> 	  discards that might be optimised by the kernel into many
> 	  overlapping async operations into small, synchronous
> 	  discards?

FWIW, I had simply suggested to Pavel that he follow e2fsprogs' lead
here - afaik they haven't had issues/complaints with their 2g iteration,
and at one point Lukas did some investigation into the size selection...

Thanks,
-Eric
 
> i.e. the reviewer can read what the patch does, but that deosn't
> explain why the patch does this. Hence it's a good idea to explain
> the problem being solved or the feature requirements that have lead
> to the changes in the patch....
> 
> Cheers,
> 
> Dave.
> 

  parent reply	other threads:[~2019-11-22 21:10 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 [this message]
2019-11-22 21:30       ` Eric Sandeen
2019-11-26 19:40         ` Eric Sandeen
2019-11-26 20:53   ` Eric Sandeen
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=b2bc2dea-575b-959a-0025-d5d20d733a55@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --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).