From: Christoph Hellwig <hch@lst.de>
To: Robert Pang <robertpang@google.com>
Cc: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Zhang Yi <yi.zhang@huaweicloud.com>,
bmarzins@redhat.com, brauner@kernel.org, chaitanyak@nvidia.com,
chengzhihao1@huawei.com, djwong@kernel.org,
john.g.garry@oracle.com, martin.petersen@oracle.com,
shinichiro.kawasaki@wdc.com, tytso@mit.edu, yangerkun@huawei.com,
yi.zhang@huawei.com, yukuai3@huawei.com,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: honor NVME_QUIRK_DEALLOCATE_ZEROES for unmap Write Zeroes
Date: Fri, 6 Mar 2026 15:24:34 +0100 [thread overview]
Message-ID: <20260306142434.GB16612@lst.de> (raw)
In-Reply-To: <20260305202735.1773922-1-robertpang@google.com>
On Thu, Mar 05, 2026 at 12:27:32PM -0800, Robert Pang wrote:
> However, certain devices already use the NVME_QUIRK_DEALLOCATE_ZEROES quirk to
> indicate that they deterministically return zeroes after a deallocate/discard
Those certain devices are completely obsolete first generation Intel
SSDs.
> Update nvme_update_disk_info() to allow the presence of the DEALLOCATE_ZEROES
> quirk (combined with DSM support) to set max_hw_wzeroes_unmap_sectors to enable
No. This was a hack that got sneaked in in the first days of the nvme
driver and never should have been there. It most certainly should not
be extended to any new functionality.
next prev parent reply other threads:[~2026-03-06 14:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 20:27 [PATCH] nvme: honor NVME_QUIRK_DEALLOCATE_ZEROES for unmap Write Zeroes Robert Pang
2026-03-06 14:24 ` Christoph Hellwig [this message]
2026-03-10 17:14 ` Robert Pang
2026-03-11 2:55 ` Zhang Yi
2026-03-13 0:06 ` Robert Pang
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=20260306142434.GB16612@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=bmarzins@redhat.com \
--cc=brauner@kernel.org \
--cc=chaitanyak@nvidia.com \
--cc=chengzhihao1@huawei.com \
--cc=djwong@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=robertpang@google.com \
--cc=sagi@grimberg.me \
--cc=shinichiro.kawasaki@wdc.com \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.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