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: <5e4cfa32-83bc-4025-a5db-298b7c080037@huaweicloud.com>
Date: Fri, 7 Feb 2025 20:31:16 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: John Garry <john.g.garry@...cle.com>
Cc: linux-kernel@...r.kernel.org, hch@....de, tytso@....edu,
 djwong@...nel.org, chengzhihao1@...wei.com, yukuai3@...wei.com,
 yangerkun@...wei.com, Zhang Yi <yi.zhang@...wei.com>,
 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
Subject: Re: [RFC PATCH v2 1/8] block: introduce BLK_FEAT_WRITE_ZEROES_UNMAP
 to queue limits features

On 2025/2/7 20:22, Zhang Yi wrote:
> On 2025/1/29 0:46, John Garry wrote:
>> On 15/01/2025 11:46, Zhang Yi wrote:
>>> From: Zhang Yi <yi.zhang@...wei.com>
>>>
>>> Currently, it's hard to know whether the storage device supports unmap
>>> write zeroes. We cannot determine it only by checking if the disk
>>> supports the write zeroes command, as for some HDDs that do submit
>>> actual zeros to the disk media even if they claim to support the write
>>> zeroes command, but that should be very slow.
>>
>> This second sentence is too long, such that your meaning is hard to understand.
>>
>>>
>>> Therefor, add a new queue limit feature, BLK_FEAT_WRITE_ZEROES_UNMAP and
>>
>> Therefore?
>>
>>> the corresponding sysfs entry, to indicate whether the block device
>>> explicitly supports the unmapped write zeroes command. Each device
>>> driver should set this bit if it is certain that the attached disk
>>> supports this command. 
>>
>> How can they be certain? You already wrote that some claim to support it, yet don't really. Well, I think that is what you meant.
>>
> 
> Hi, John. thanks for your reply!
> 
> Sorry for the late and not make it clear enough earlier. Currently, there
> are four situations of write zeroes command (aka REQ_OP_WRITE_ZEROES)
> supported by various disks and backend storage devices.
> 
> A. Devices that do not support the write zeroes command
>    These devices have bdev_limits(bdev)->max_write_zeroes_sectors set to
>    zero.
> B. Devices that support the write zeroes command
>    These devices have bdev_limits(bdev)->max_write_zeroes_sectors set to a
>    non-zero value. They can be further categorized into three
>    sub-situations:
> B.1. Devices that write physical zeroes to the media
>      These devices perform the write zeroes operation by physically writing
>      zeroes to the storage media, which can be very slow (e.g., HDDs).
> B.2. Devices that support unmap write zeroes
>      These devices can offload the write zeroes operation by unmapping the
>      logical blocks, effectively putting them into a deallocated state
>      (e.g., SSDs). This operation is typically very fast, allowing
>      filesystems to use this command to quickly create zeroed files. NVMe
>      and SCSI disk drivers already support this and can query the attached
>      disks to determine whether they support unmap write zeroes (please see
>      patches 2 and 3 for details).
> B.3. The implementation of write zeroes on disks are unknown
>      This category includes non-standard disks and some network storage
>      devices where the exact implementation of the write zeroes command is
>      unclear.
> 
> Currently, users can only distinguish A and B through querying
> 
>    /sys/block/<disk>/queue/write_zeroes_unmap
                             ^^^^^^^^^^^^^^^^^^
Oh, sorry, it should be 'write_zeroes_max_bytes'

     /sys/block/<disk>/queue/write_zeroes_max_bytes

Thanks,
Yi.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ