From: Dave Chinner <david@fromorbit.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
xfs@oss.sgi.com
Subject: Re: [PATCH 0/2] Add FALLOC_FL_ZERO_RANGE to fallocate
Date: Thu, 14 Jun 2012 09:51:31 +1000 [thread overview]
Message-ID: <20120613235131.GW22848@dastard> (raw)
In-Reply-To: <4FD82F89.80106@redhat.com>
On Wed, Jun 13, 2012 at 08:13:29AM +0200, Paolo Bonzini wrote:
> Il 13/06/2012 05:30, Dave Chinner ha scritto:
> >> >
> >> > Also, a minor nit, but you should credit where this code has
> >> > originated from in the commit messages, and describe the use case
> >> > for requiring it. i.e. based on:
> >> >
> >> > http://permalink.gmane.org/gmane.linux.file-systems/62449
>
> Interesting, I didn't know this---I wrote the code from scratch.
>
> I took the description from the man pages ("This operation is a fast
> method of overwriting any from the range specified with zeros without
> removing any blocks or having to write zeros to disk"), so perhaps those
> will have to be patched as well.
The first line of the man page description is the important one:
$ man 3 xfsctl
.....
XFS_IOC_ZERO_RANGE
This command is used to convert a range of a file to zeros
without issuing data IO. ....
The rest of the description is details about the implementation in
XFS, so users have some idea what to expect in terms or behaviour.
The line that you quoted:
This operation is a fast method of overwriting any from the
range specified with zeros without removing any blocks or
having to write zeros to disk.
describes how the implementation is different from hole punching
(i.e XFS_IOC_UNRESVSP). All the stuff about unwritten extents is
copied directly from the about XFS_IOC_RESVSP preallocation
description to provide consistent information in the man page.
The XFS_IOC_ZERO_RANGE man page is not a requirements specification
- it's user-level documentation. Yes, it describes the
implementation, but does not convey any of the reasons that the
functionality was implemented that way. Hence using that as the
requirements spec for equivalent fallocate functionality will miss
the mark...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2012-06-13 23:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-12 15:36 [PATCH 0/2] Add FALLOC_FL_ZERO_RANGE to fallocate Paolo Bonzini
2012-06-12 15:36 ` [PATCH 1/2] vfs: add " Paolo Bonzini
2012-06-13 1:55 ` Dave Chinner
2012-06-12 15:36 ` [PATCH 2/2] xfs: " Paolo Bonzini
2012-06-13 2:16 ` Dave Chinner
2012-06-13 6:24 ` Paolo Bonzini
2012-06-13 23:52 ` Dave Chinner
2012-06-13 1:35 ` [PATCH 0/2] Add " Dave Chinner
2012-06-13 3:30 ` Dave Chinner
2012-06-13 6:13 ` Paolo Bonzini
2012-06-13 23:51 ` Dave Chinner [this message]
2013-11-05 10:34 ` Christoph Hellwig
2013-11-05 10:36 ` Paolo Bonzini
2013-11-05 16:36 ` Christoph Hellwig
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=20120613235131.GW22848@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xfs@oss.sgi.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).