linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhang Yi <yi.zhang@huaweicloud.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
	dm-devel@lists.linux.dev, linux-nvme@lists.infradead.org,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, hch@lst.de, tytso@mit.edu,
	bmarzins@redhat.com, chaitanyak@nvidia.com,
	shinichiro.kawasaki@wdc.com, brauner@kernel.org,
	martin.petersen@oracle.com, yi.zhang@huawei.com,
	chengzhihao1@huawei.com, yukuai3@huawei.com,
	yangerkun@huawei.com
Subject: Re: [PATCH util-linux v2] fallocate: add FALLOC_FL_WRITE_ZEROES support
Date: Mon, 18 Aug 2025 10:17:14 +0800	[thread overview]
Message-ID: <4798d44a-4aa5-4b95-a3f4-25be3d8ee35a@huaweicloud.com> (raw)
In-Reply-To: <20250815142908.GG7981@frogsfrogsfrogs>

On 8/15/2025 10:29 PM, Darrick J. Wong wrote:
> On Fri, Aug 15, 2025 at 05:29:19PM +0800, Zhang Yi wrote:
>> Thank you for your review comments!
>>
>> On 2025/8/15 0:52, Darrick J. Wong wrote:
>>> On Wed, Aug 13, 2025 at 10:40:15AM +0800, Zhang Yi wrote:
>>>> From: Zhang Yi <yi.zhang@huawei.com>
>>>>
>>>> The Linux kernel (since version 6.17) supports FALLOC_FL_WRITE_ZEROES in
>>>> fallocate(2). Add support for FALLOC_FL_WRITE_ZEROES to the fallocate
>>>> utility by introducing a new option -w|--write-zeroes.
>>>>
>>>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=278c7d9b5e0c
>>>> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
>>>> ---
>>>> v1->v2:
>>>>  - Minor description modification to align with the kernel.
>>>>
>>>>  sys-utils/fallocate.1.adoc | 11 +++++++++--
>>>>  sys-utils/fallocate.c      | 20 ++++++++++++++++----
>>>>  2 files changed, 25 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/sys-utils/fallocate.1.adoc b/sys-utils/fallocate.1.adoc
>>>> index 44ee0ef4c..0ec9ff9a9 100644
>>>> --- a/sys-utils/fallocate.1.adoc
>>>> +++ b/sys-utils/fallocate.1.adoc
>>>> @@ -12,7 +12,7 @@ fallocate - preallocate or deallocate space to a file
>>>
>>> <snip all the long lines>
>>>
>>>> +*-w*, *--write-zeroes*::
>>>> +Zeroes space in the byte range starting at _offset_ and continuing
>>>> for _length_ bytes. Within the specified range, blocks are
>>>> preallocated for the regions that span the holes in the file. After a
>>>> successful call, subsequent reads from this range will return zeroes,
>>>> subsequent writes to that range do not require further changes to the
>>>> file mapping metadata.
>>>
>>> "...will return zeroes and subsequent writes to that range..." ?
>>>
>>
>> Yeah.
>>
>>>> ++
>>>> +Zeroing is done within the filesystem by preferably submitting write
>>>
>>> I think we should say less about what the filesystem actually does to
>>> preserve some flexibility:
>>>
>>> "Zeroing is done within the filesystem. The filesystem may use a
>>> hardware accelerated zeroing command, or it may submit regular writes.
>>> The behavior depends on the filesystem design and available hardware."
>>>
>>
>> Sure.
>>
>>>> zeores commands, the alternative way is submitting actual zeroed data,
>>>> the specified range will be converted into written extents. The write
>>>> zeroes command is typically faster than write actual data if the
>>>> device supports unmap write zeroes, the specified range will not be
>>>> physically zeroed out on the device.
>>>> ++
>>>> +Options *--keep-size* can not be specified for the write-zeroes
>>>> operation.
>>>> +
>>>>  include::man-common/help-version.adoc[]
>>>>  
>>>>  == AUTHORS
>> [..]
>>>> @@ -429,6 +438,9 @@ int main(int argc, char **argv)
>>>>  			else if (mode & FALLOC_FL_ZERO_RANGE)
>>>>  				fprintf(stdout, _("%s: %s (%ju bytes) zeroed.\n"),
>>>>  								filename, str, length);
>>>> +			else if (mode & FALLOC_FL_WRITE_ZEROES)
>>>> +				fprintf(stdout, _("%s: %s (%ju bytes) write zeroed.\n"),
>>>
>>> "write zeroed" is a little strange, but I don't have a better
>>> suggestion. :)
>>>
>>
>> Hmm... What about simply using "zeroed", the same to FALLOC_FL_ZERO_RANGE?
>> Users should be aware of the parameters they have passed to fallocate(),
>> so they should not use this print for further differentiation.
> 
> No thanks, different inputs should produce different outputs. :)
> 

OK. perhaps "written as zeros." ? Sounds OK?

Thanks,
Yi.



      reply	other threads:[~2025-08-18  2:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13  2:40 [PATCH util-linux v2] fallocate: add FALLOC_FL_WRITE_ZEROES support Zhang Yi
2025-08-14 16:52 ` Darrick J. Wong
2025-08-15  9:29   ` Zhang Yi
2025-08-15 14:29     ` Darrick J. Wong
2025-08-18  2:17       ` Zhang Yi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4798d44a-4aa5-4b95-a3f4-25be3d8ee35a@huaweicloud.com \
    --to=yi.zhang@huaweicloud.com \
    --cc=bmarzins@redhat.com \
    --cc=brauner@kernel.org \
    --cc=chaitanyak@nvidia.com \
    --cc=chengzhihao1@huawei.com \
    --cc=djwong@kernel.org \
    --cc=dm-devel@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=tytso@mit.edu \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).