[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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