public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: sagi@grimberg.me, axboe@kernel.dk,
	linux-nvme@lists.infradead.org,
	Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com>
Subject: Re: [PATCH] nvme: don't apply NVME_QUIRK_DEALLOCATE_ZEROES when DSM is not supported
Date: Wed, 27 Nov 2024 08:45:04 -0700	[thread overview]
Message-ID: <Z0c-gFbw4n0SaKD9@kbusch-mbp> (raw)
In-Reply-To: <20241127064218.42688-1-hch@lst.de>

On Wed, Nov 27, 2024 at 07:42:18AM +0100, Christoph Hellwig wrote:
> Commit 63dfa1004322 ("nvme: move NVME_QUIRK_DEALLOCATE_ZEROES out of
> nvme_config_discard") started applying the NVME_QUIRK_DEALLOCATE_ZEROES
> quirk even then the Dataset Management is not supported.  It turns out
> that there versions of these old Intel SSDs that have DSM support
> disabled in the firmware, which will now lead to errors everytime
> a Write Zeroes command is issued.  Fix this by checking for DSM support
> before applying the quirk.

I still think this is wrong, and we should just remove the quirk for
this device. With the exception to this firmware version, this device
generally supports both discards and write zeroes. The only reason it
added this quirk was because the quirk used to mean something completely
different (specifically, it would set the "discard_zeroes_data"
attribute that's no longer used). It didn't mean to prefer discards over
write zeroes, but that's what it means now, and that's not what this
drive wants.


  parent reply	other threads:[~2024-11-27 15:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20241127152849epcas5p3872af708d33fbfb00fd3b703b879b273@epcas5p3.samsung.com>
2024-11-27  6:42 ` [PATCH] nvme: don't apply NVME_QUIRK_DEALLOCATE_ZEROES when DSM is not supported Christoph Hellwig
2024-11-27  7:48   ` Chaitanya Kulkarni
2024-11-27 15:20   ` Nitesh Shetty
2024-11-27 15:45   ` Keith Busch [this message]
2024-11-27 15:48     ` Christoph Hellwig
2024-11-27 15:52       ` Keith Busch
2024-12-02 17:54   ` Keith Busch
2024-12-02 18:03     ` Saeed Mirzamohammadi
2024-12-02 18:08       ` 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=Z0c-gFbw4n0SaKD9@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-nvme@lists.infradead.org \
    --cc=saeed.mirzamohammadi@oracle.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox