linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu,
	linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate
Date: Thu, 13 Mar 2014 19:49:36 +1100	[thread overview]
Message-ID: <20140313084936.GF4263@dastard> (raw)
In-Reply-To: <1393355679-11160-1-git-send-email-lczerner@redhat.com>

On Tue, Feb 25, 2014 at 08:14:33PM +0100, Lukas Czerner wrote:
> Introduce new FALLOC_FL_ZERO_RANGE flag for fallocate. This has the same
> functionality as xfs ioctl XFS_IOC_ZERO_RANGE.
> 
> It can be used to convert a range of file to zeros preferably without
> issuing data IO. Blocks should be preallocated for the regions that span
> holes in the file, and the entire range is preferable converted to
> unwritten extents - even though file system may choose to zero out the
> extent or do whatever which will result in reading zeros from the range
> while the range remains allocated for the file.
> 
> This can be also used to preallocate blocks past EOF in the same way as
> with fallocate. Flag FALLOC_FL_KEEP_SIZE which should cause the inode
> size to remain the same.
> 
> You can test this feature yourself using xfstests, of fallocate(1) however
> you'll need patches for util_linux, xfsprogs and xfstests which are going to
> follow soon.
> 
> I tested this mostly with a subset of xfstests using fsx and fsstress and
> even with new generic/290 which is just a copy of xfs/290 using fzero
> command for xfs_io instead of zero (which uses ioctl). I was testing on
> x86_64 and ppc64 with block sizes of 1024, 2048 and 4096.
> 
> ./check generic/076 generic/232 generic/013 generic/070 generic/269 generic/083
> generic/117 generic/068 generic/231 generic/127 generic/091 generic/075
> generic/112 generic/263 generic/091 generic/075 generic/256 generic/255
> generic/316 generic/300 generic/290 ext4/242;
> 
> Note that there is a work in progress on FALLOC_FL_COLLAPSE_RANGE which
> touches the same area as this pach set does, so we should figure out
> which one should go first and modify the other on top of it.
> 
> This has been based on top of xfs-collapse-range so it does not contain ext4
> collapse range changes.

Lukas, I have merged patches 4 and 6 into the xfs-collapse-branch.
That branch should now remain stable, so you can rebase all the ext4
collapse range and zero range bits on top of tha branch and Ted can
pull it into the ext4 tree if he wants to pull it in.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2014-03-13  8:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 19:14 [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate Lukas Czerner
2014-02-25 19:14 ` [PATCH 1/6 v2] ext4: Update inode i_size after the preallocation Lukas Czerner
2014-03-16  3:27   ` tytso
2014-03-17  3:02   ` tytso
2014-03-17 10:48     ` Lukáš Czerner
2014-02-25 19:14 ` [PATCH 2/6 v2] ext4: refactor ext4_fallocate code Lukas Czerner
2014-03-16  3:28   ` tytso
2014-02-25 19:14 ` [PATCH 3/6 v2] ext4: translate fallocate mode bits to strings Lukas Czerner
2014-02-25 19:14 ` [PATCH 4/6 v2] fs: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate Lukas Czerner
2014-02-25 19:14 ` [PATCH 5/6 v2] ext4: " Lukas Czerner
2014-02-26  6:00   ` jon ernst
2014-02-27  4:41     ` jon ernst
2014-02-27 11:56       ` Lukáš Czerner
2014-03-16  4:13   ` tytso
2014-02-25 19:14 ` [PATCH 6/6 v2] xfs: Add support for FALLOC_FL_ZERO_RANGE Lukas Czerner
2014-03-13  8:49 ` Dave Chinner [this message]
2014-03-13 10:14   ` [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate Lukáš Czerner

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=20140313084936.GF4263@dastard \
    --to=david@fromorbit.com \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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).