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: <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
Powered by blists - more mailing lists