From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Zhang Yi <yi.zhang@huaweicloud.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-block@vger.kernel.org, dm-devel@lists.linux.dev,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
hch@lst.de, tytso@mit.edu, djwong@kernel.org,
john.g.garry@oracle.com, bmarzins@redhat.com,
chaitanyak@nvidia.com, shinichiro.kawasaki@wdc.com,
brauner@kernel.org, yi.zhang@huawei.com, chengzhihao1@huawei.com,
yukuai3@huawei.com, yangerkun@huawei.com
Subject: Re: [RFC PATCH v4 01/11] block: introduce BLK_FEAT_WRITE_ZEROES_UNMAP to queue limits features
Date: Tue, 06 May 2025 00:21:36 -0400 [thread overview]
Message-ID: <yq18qnav4zj.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <20250421021509.2366003-2-yi.zhang@huaweicloud.com> (Zhang Yi's message of "Mon, 21 Apr 2025 10:14:59 +0800")
Hi Zhang!
> + [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. If the write_zeroes_unmap is set to 1, this indicates
> + that the device explicitly supports the write zero command.
> + However, this may be a best-effort optimization rather than a
> + mandatory requirement, some devices may partially fall back to
> + writing physical zeroes due to factors such as receiving
> + unaligned commands. If the parameter is set to 0, the device
> + either does not support this operation, or its support status is
> + unknown.
I am not so keen on mixing Write Zeroes (which is NVMe-speak) and Unmap
(which is SCSI). Also, Deallocate and Unmap reflect block provisioning
state on the device but don't really convey what is semantically
important for your proposed change (zeroing speed and/or media wear
reduction).
That said, I'm having a hard time coming up with a better term.
WRITE_ZEROES_OPTIMIZED, maybe? Naming is hard...
For the description, perhaps something like the following which tries to
focus on the block layer semantics without using protocol-specific
terminology?
[RO] This parameter indicates whether a device supports zeroing data in
a specified block range without incurring the cost of physically writing
zeroes to media for each individual block. This operation is a
best-effort optimization, a device may fall back to physically writing
zeroes to media due to other factors such as misalignment or being asked
to clear a block range smaller than the device's internal allocation
unit. If write_zeroes_unmap is set to 1, the device implements a zeroing
operation which opportunistically avoids writing zeroes to media while
still guaranteeing that subsequent reads from the specified block range
will return zeroed data. If write_zeroes_unmap is set to 0, the device
may have to write each logical block media during a zeroing operation.
--
Martin K. Petersen
next prev parent reply other threads:[~2025-05-06 4:27 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 2:14 [RFC PATCH v4 00/11] fallocate: introduce FALLOC_FL_WRITE_ZEROES flag Zhang Yi
2025-04-21 2:14 ` [RFC PATCH v4 01/11] block: introduce BLK_FEAT_WRITE_ZEROES_UNMAP to queue limits features Zhang Yi
2025-05-05 11:54 ` Christoph Hellwig
2025-05-06 4:21 ` Martin K. Petersen [this message]
2025-05-06 7:51 ` Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 02/11] nvme: set BLK_FEAT_WRITE_ZEROES_UNMAP if device supports DEAC bit Zhang Yi
2025-05-05 11:55 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 03/11] nvme-multipath: add BLK_FEAT_WRITE_ZEROES_UNMAP support Zhang Yi
2025-05-05 11:55 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 04/11] nvmet: set WZDS and DRB if device supports BLK_FEAT_WRITE_ZEROES_UNMAP Zhang Yi
2025-05-05 11:56 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 05/11] scsi: sd: set BLK_FEAT_WRITE_ZEROES_UNMAP if device supports unmap zeroing mode Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 06/11] dm: add BLK_FEAT_WRITE_ZEROES_UNMAP support Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 07/11] fs: statx add write zeroes unmap attribute Zhang Yi
2025-05-05 13:22 ` Christoph Hellwig
2025-05-05 14:29 ` Darrick J. Wong
2025-05-06 4:28 ` Zhang Yi
2025-05-06 4:39 ` Christoph Hellwig
2025-05-06 11:16 ` Zhang Yi
2025-05-06 12:11 ` Christoph Hellwig
2025-05-07 7:33 ` Zhang Yi
2025-05-07 21:03 ` Darrick J. Wong
2025-05-08 5:01 ` Christoph Hellwig
2025-05-08 12:17 ` Zhang Yi
2025-05-08 20:24 ` Theodore Ts'o
2025-05-09 12:35 ` Zhang Yi
2025-05-06 5:02 ` Christoph Hellwig
2025-05-06 5:36 ` Darrick J. Wong
2025-05-06 5:47 ` Christoph Hellwig
2025-05-06 11:25 ` Zhang Yi
2025-05-06 12:10 ` Christoph Hellwig
2025-05-06 15:55 ` Darrick J. Wong
2025-05-07 8:23 ` Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 08/11] fs: introduce FALLOC_FL_WRITE_ZEROES to fallocate Zhang Yi
2025-05-05 13:22 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 09/11] block: factor out common part in blkdev_fallocate() Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 10/11] block: add FALLOC_FL_WRITE_ZEROES support Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 11/11] ext4: " Zhang Yi
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=yq18qnav4zj.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=bmarzins@redhat.com \
--cc=brauner@kernel.org \
--cc=chaitanyak@nvidia.com \
--cc=chengzhihao1@huawei.com \
--cc=djwong@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--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