linux-kernel - Re: [RFC PATCH v4 01/11] block: introduce BLK_FEAT_WRITE_ZEROES

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yq18qnav4zj.fsf@ca-mkp.ca.oracle.com>
Date: Tue, 06 May 2025 00:21:36 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
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, brauner@...nel.org, yi.zhang@...wei.com,
        chengzhihao1@...wei.com, yukuai3@...wei.com, yangerkun@...wei.com
Subject: Re: [RFC PATCH v4 01/11] block: introduce
 BLK_FEAT_WRITE_ZEROES_UNMAP to queue limits features

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