[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250409103148.GA4950@lst.de>
Date: Wed, 9 Apr 2025 12:31:48 +0200
From: Christoph Hellwig <hch@....de>
To: Zhang Yi <yi.zhang@...weicloud.com>
Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-block@...r.kernel.org, dm-devel@...ts.linux.dev,
linux-nvme@...ts.infradead.org, linux-scsi@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org, hch@....de,
tytso@....edu, djwong@...nel.org, john.g.garry@...cle.com,
bmarzins@...hat.com, chaitanyak@...dia.com,
shinichiro.kawasaki@....com, yi.zhang@...wei.com,
chengzhihao1@...wei.com, yukuai3@...wei.com, yangerkun@...wei.com
Subject: Re: [RFC PATCH -next v3 01/10] block: introduce
BLK_FEAT_WRITE_ZEROES_UNMAP to queue limits features
On Tue, Mar 18, 2025 at 03:35:36PM +0800, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@...wei.com>
>
> Currently, disks primarily implement the write zeroes command (aka
> REQ_OP_WRITE_ZEROES) through two mechanisms: the first involves
> physically writing zeros to the disk media (e.g., HDDs), while the
> second performs an unmap operation on the logical blocks, effectively
> putting them into a deallocated state (e.g., SSDs). The first method is
> generally slow, while the second method is typically very fast.
>
> For example, on certain NVMe SSDs that support NVME_NS_DEAC, submitting
> REQ_OP_WRITE_ZEROES requests with the NVME_WZ_DEAC bit can accelerate
> the write zeros operation by placing disk blocks into
Note that this is a can, not a must. The NVMe definition of Write
Zeroes is unfortunately pretty stupid.
> + [RO] Devices that explicitly support the unmap write zeroes
> + operation in which a single write zeroes request with the unmap
> + bit set to zero out the range of contiguous blocks on storage
> + by freeing blocks, rather than writing physical zeroes to the
> + media.
This is not actually guaranteed for nvme or scsi.
Powered by blists - more mailing lists