All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Sagi Grimberg <sagi@grimberg.me>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 3/4] nvme: fix max_discard_sectors calculation
Date: Tue, 2 Jan 2024 10:28:16 -0700	[thread overview]
Message-ID: <ZZRHsFrdL2OcO_Cb@kbusch-mbp> (raw)
In-Reply-To: <20231226085844.203878-4-hch@lst.de>

On Tue, Dec 26, 2023 at 08:58:43AM +0000, Christoph Hellwig wrote:
> ctrl->max_discard_sectors stores a value that is potentially based of
> the DMRSL field in Identify Controller, which is in units of LBAs and
> thus dependent on the Format of a namespace.

Is it just me, or is this one of the more annoying conventions in NVMe
standard: controller scoped identification fields are in units of
namespace specific formats?! Why not define these in namespace
identifications, or provide a fixed unit size? As it is now, these types
of fields would be in units of the largest LBA size of any attached
namespace, and that's kind of awkward in a multi-namespace environment.
 
> @@ -1750,7 +1751,7 @@ static void nvme_config_discard(struct nvme_ctrl *ctrl, struct gendisk *disk,
>  	if (queue->limits.max_discard_sectors)
>  		return;

Since DMRSL can change when you format a namespace to a new LBA size,
might the old limit be using the wrong max_discard_size if we skip
updating it here? Probably not a big deal.

And let's say the user explicitly disabled max_discard_sectors through
sysfs. The next driver namespace rescan will turn it back on, probably
against the user's expectations. Should this limit check use
'max_hw_discard_sectors' instead?

Anyway, the driver was like that already, and the series looks good to
me. I just noticed this weirdness while reviewing.

> -	blk_queue_max_discard_sectors(queue, ctrl->max_discard_sectors);
> +	blk_queue_max_discard_sectors(queue, max_discard_sectors);
>  	blk_queue_max_discard_segments(queue, ctrl->max_discard_segments);
>  	queue->limits.discard_granularity = queue_logical_block_size(queue);


  reply	other threads:[~2024-01-02 17:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-26  8:58 nvme discard limits fix and tidy ups Christoph Hellwig
2023-12-26  8:58 ` [PATCH 1/4] nvme: update the explanation for not updating the limits in nvme_config_discard Christoph Hellwig
2023-12-26  8:58 ` [PATCH 2/4] nvme: also skip discard granularity updates " Christoph Hellwig
2023-12-26 23:18   ` Max Gurtovoy
2023-12-27  8:07     ` Christoph Hellwig
2023-12-26  8:58 ` [PATCH 3/4] nvme: fix max_discard_sectors calculation Christoph Hellwig
2024-01-02 17:28   ` Keith Busch [this message]
2023-12-26  8:58 ` [PATCH 4/4] nvme: simplify the max_discard_segments calculation Christoph Hellwig
2024-01-02 21:36 ` nvme discard limits fix and tidy ups Keith Busch
  -- strict thread matches above, loose matches on Subject: below --
2023-07-07  9:46 fix discard limits Christoph Hellwig
2023-07-07  9:46 ` [PATCH 3/4] nvme: fix max_discard_sectors calculation Christoph Hellwig
2023-07-10  3:57   ` Damien Le Moal
2023-07-10  6:39     ` Christoph Hellwig
2023-07-10  9:31   ` Sagi Grimberg

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=ZZRHsFrdL2OcO_Cb@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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.