[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41c21e20-5439-4157-ad73-6f133df42d28@huaweicloud.com>
Date: Thu, 12 Jun 2025 19:20:45 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: Christoph Hellwig <hch@....de>
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, tytso@....edu,
djwong@...nel.org, john.g.garry@...cle.com, bmarzins@...hat.com,
chaitanyak@...dia.com, shinichiro.kawasaki@....com, brauner@...nel.org,
martin.petersen@...cle.com, yi.zhang@...wei.com, chengzhihao1@...wei.com,
yukuai3@...wei.com, yangerkun@...wei.com
Subject: Re: [PATCH 01/10] block: introduce BLK_FEAT_WRITE_ZEROES_UNMAP to
queue limits features
On 2025/6/12 12:47, Christoph Hellwig wrote:
> On Wed, Jun 11, 2025 at 03:31:21PM +0800, Zhang Yi wrote:
>>>> +/* supports unmap write zeroes command */
>>>> +#define BLK_FEAT_WRITE_ZEROES_UNMAP ((__force blk_features_t)(1u << 17))
>>>
>>>
>>> Should this be exposed through sysfs as a read-only value?
>>
>> Uh, are you suggesting adding another sysfs interface to expose
>> this feature?
>
> That was the idea. Or do we have another way to report this capability?
>
Exposing this feature looks useful, but I think adding a new interface
might be somewhat redundant, and it's also difficult to name the new
interface. What about extend this interface to include 3 types? When
read, it exposes the following:
- none : the device doesn't support BLK_FEAT_WRITE_ZEROES_UNMAP.
- enabled : the device supports BLK_FEAT_WRITE_ZEROES_UNMAP, but the
BLK_FLAG_WRITE_ZEROES_UNMAP_DISABLED is not set.
- disabled : the device supports BLK_FEAT_WRITE_ZEROES_UNMAP, and the
BLK_FLAG_WRITE_ZEROES_UNMAP_DISABLED is set.
Users can write '0' and '1' to disable and enable this operation if it
is not 'none', thoughts?
Best regards,
Yi.
Powered by blists - more mailing lists