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
| ||
|
Message-ID: <52c1dd13-1a04-4d9a-b687-639ed348474e@huaweicloud.com> Date: Tue, 6 May 2025 15:51:13 +0800 From: Zhang Yi <yi.zhang@...weicloud.com> To: "Martin K. Petersen" <martin.petersen@...cle.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, Martin! On 2025/5/6 12:21, Martin K. Petersen wrote: > > 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). > Since this flag doesn't strictly guarantee zeroing speed or media wear reduction optimizations, but rather reflects typical optimization behavior across most supported devices and cases. Therefore, I propose using a name that accurately indicates the function of the block device. However, also can't think of a better name either. Using the name WRITE_ZEROES_UNMAP seems appropriate to convey that the block device supports this type of Deallocate and Unmap state. > That said, I'm having a hard time coming up with a better term. > WRITE_ZEROES_OPTIMIZED, maybe? Naming is hard... Using WRITE_ZEROES_OPTIMIZED feels somewhat too generic to me, and users may not fully grasp the specific optimizations it entails based on the name. > > 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. > Thank you for optimizing the description, it looks good to me. I'd like to this one in my next iteration. :) Thanks, Yi.
Powered by blists - more mailing lists