From: Dave Chinner <david@fromorbit.com>
To: Ted Ts'o <tytso@mit.edu>, Josef Bacik <josef@redhat.com>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
xfs@oss
Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate
Date: Tue, 9 Nov 2010 15:42:42 +1100 [thread overview]
Message-ID: <20101109044242.GH2715@dastard> (raw)
In-Reply-To: <20101109033038.GF3099@thunk.org>
On Mon, Nov 08, 2010 at 10:30:38PM -0500, Ted Ts'o wrote:
> On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
> > Hole punching was not included originally in fallocate() for a
> > variety of reasons. IIRC, they were along the lines of:
> >
> > 1 de-allocating of blocks in an allocation syscall is wrong.
> > People wanted a new syscall for this functionality.
....
> > I guess that leaves #1 to be debated;
> > I don't think there is any problem with doing what you propose.
>
> I don't have a problem either.
>
> As a completely separate proposal, what do people think about an
> FALLOCATE_FL_ZEROIZE after which time the blocks are allocated, but
> reading from them returns zero.
That's exactly the new XFS_IOC_ZERO_RANGE ioctl in 2.6.36 does
(commit 447223520520b17d3b6d0631aa4838fbaf8eddb4 "xfs: Introduce
XFS_IOC_ZERO_RANGE") The git commit I pointed to in the last email
is the rudimentary fallocate() interface support I have for that
code which goes along with an xfs_io patch I have. Given that there
seems to be interest for this operation, I'll flesh it out into a
proper patch....
> This could be done either by (a)
> sending a discard in the case of devices where discard_zeros_data is
> true and discard_granularty is less than the fs block size, or (b) by
> setting the uninitialized flag in the extent tree.
Implementation is up to the filesystem. However, XFS does (b)
because:
1) it was extremely simple to implement (one of the
advantages of having an exceedingly complex allocation
interface to begin with :P)
2) conversion is atomic, fast and reliable
3) it is independent of the underlying storage; and
4) reads of unwritten extents operate at memory speed,
not disk speed.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: "Ted Ts'o" <tytso@mit.edu>, Josef Bacik <josef@redhat.com>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
xfs@oss.sgi.com, joel.becker@oracle.com, cmm@us.ibm.com,
cluster-devel@redhat.com
Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate
Date: Tue, 9 Nov 2010 15:42:42 +1100 [thread overview]
Message-ID: <20101109044242.GH2715@dastard> (raw)
In-Reply-To: <20101109033038.GF3099@thunk.org>
On Mon, Nov 08, 2010 at 10:30:38PM -0500, Ted Ts'o wrote:
> On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
> > Hole punching was not included originally in fallocate() for a
> > variety of reasons. IIRC, they were along the lines of:
> >
> > 1 de-allocating of blocks in an allocation syscall is wrong.
> > People wanted a new syscall for this functionality.
....
> > I guess that leaves #1 to be debated;
> > I don't think there is any problem with doing what you propose.
>
> I don't have a problem either.
>
> As a completely separate proposal, what do people think about an
> FALLOCATE_FL_ZEROIZE after which time the blocks are allocated, but
> reading from them returns zero.
That's exactly the new XFS_IOC_ZERO_RANGE ioctl in 2.6.36 does
(commit 447223520520b17d3b6d0631aa4838fbaf8eddb4 "xfs: Introduce
XFS_IOC_ZERO_RANGE") The git commit I pointed to in the last email
is the rudimentary fallocate() interface support I have for that
code which goes along with an xfs_io patch I have. Given that there
seems to be interest for this operation, I'll flesh it out into a
proper patch....
> This could be done either by (a)
> sending a discard in the case of devices where discard_zeros_data is
> true and discard_granularty is less than the fs block size, or (b) by
> setting the uninitialized flag in the extent tree.
Implementation is up to the filesystem. However, XFS does (b)
because:
1) it was extremely simple to implement (one of the
advantages of having an exceedingly complex allocation
interface to begin with :P)
2) conversion is atomic, fast and reliable
3) it is independent of the underlying storage; and
4) reads of unwritten extents operate at memory speed,
not disk speed.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Ted Ts'o <tytso@mit.edu>, Josef Bacik <josef@redhat.com>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
xfs@oss.sgi.com, joel.becker@oracle.com, cmm@us.ibm.com,
cluster-devel@redhat.com
Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate
Date: Tue, 9 Nov 2010 15:42:42 +1100 [thread overview]
Message-ID: <20101109044242.GH2715@dastard> (raw)
In-Reply-To: <20101109033038.GF3099@thunk.org>
On Mon, Nov 08, 2010 at 10:30:38PM -0500, Ted Ts'o wrote:
> On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
> > Hole punching was not included originally in fallocate() for a
> > variety of reasons. IIRC, they were along the lines of:
> >
> > 1 de-allocating of blocks in an allocation syscall is wrong.
> > People wanted a new syscall for this functionality.
....
> > I guess that leaves #1 to be debated;
> > I don't think there is any problem with doing what you propose.
>
> I don't have a problem either.
>
> As a completely separate proposal, what do people think about an
> FALLOCATE_FL_ZEROIZE after which time the blocks are allocated, but
> reading from them returns zero.
That's exactly the new XFS_IOC_ZERO_RANGE ioctl in 2.6.36 does
(commit 447223520520b17d3b6d0631aa4838fbaf8eddb4 "xfs: Introduce
XFS_IOC_ZERO_RANGE") The git commit I pointed to in the last email
is the rudimentary fallocate() interface support I have for that
code which goes along with an xfs_io patch I have. Given that there
seems to be interest for this operation, I'll flesh it out into a
proper patch....
> This could be done either by (a)
> sending a discard in the case of devices where discard_zeros_data is
> true and discard_granularty is less than the fs block size, or (b) by
> setting the uninitialized flag in the extent tree.
Implementation is up to the filesystem. However, XFS does (b)
because:
1) it was extremely simple to implement (one of the
advantages of having an exceedingly complex allocation
interface to begin with :P)
2) conversion is atomic, fast and reliable
3) it is independent of the underlying storage; and
4) reads of unwritten extents operate at memory speed,
not disk speed.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-11-09 4:42 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 20:32 [PATCH 1/6] fs: add hole punching to fallocate Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` [PATCH 2/6] XFS: handle hole punching via fallocate properly Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-09 1:22 ` Dave Chinner
2010-11-09 1:22 ` Dave Chinner
2010-11-09 2:05 ` Josef Bacik
2010-11-09 2:05 ` Josef Bacik
2010-11-09 4:21 ` Dave Chinner
2010-11-09 4:21 ` Dave Chinner
2010-11-08 20:32 ` [PATCH 3/6] Ocfs2: " Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` [PATCH 4/6] Ext4: fail if we try to use hole punch Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` [PATCH 5/6] Btrfs: " Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-09 10:05 ` Will Newton
2010-11-09 10:05 ` Will Newton
2010-11-09 10:05 ` Will Newton
2010-11-09 10:05 ` Will Newton
2010-11-09 12:53 ` Josef Bacik
2010-11-09 12:53 ` Josef Bacik
2010-11-09 12:53 ` Josef Bacik
2010-11-09 12:53 ` Josef Bacik
2010-11-08 20:32 ` [PATCH 6/6] Gfs2: " Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-09 1:12 ` [PATCH 1/6] fs: add hole punching to fallocate Dave Chinner
2010-11-09 1:12 ` Dave Chinner
2010-11-09 2:10 ` Josef Bacik
2010-11-09 2:10 ` Josef Bacik
2010-11-09 3:30 ` Ted Ts'o
2010-11-09 3:30 ` Ted Ts'o
2010-11-09 4:42 ` Dave Chinner [this message]
2010-11-09 4:42 ` Dave Chinner
2010-11-09 4:42 ` Dave Chinner
2010-11-09 21:41 ` Ted Ts'o
2010-11-09 21:41 ` Ted Ts'o
2010-11-09 21:53 ` Jan Kara
2010-11-09 21:53 ` [Cluster-devel] " Jan Kara
2010-11-09 21:53 ` Jan Kara
2010-11-09 23:40 ` Dave Chinner
2010-11-09 23:40 ` Dave Chinner
2010-11-09 23:40 ` Dave Chinner
2010-11-09 23:40 ` Dave Chinner
2011-01-11 21:13 ` Lawrence Greenfield
2011-01-11 21:13 ` Lawrence Greenfield
2011-01-11 21:13 ` Lawrence Greenfield
2011-01-11 21:13 ` Lawrence Greenfield
2011-01-11 21:30 ` Ted Ts'o
2011-01-11 21:30 ` Ted Ts'o
2011-01-12 11:48 ` Dave Chinner
2011-01-12 11:48 ` Dave Chinner
2011-01-12 11:48 ` Dave Chinner
2011-01-12 11:48 ` Dave Chinner
2011-01-12 12:44 ` Dave Chinner
2011-01-12 12:44 ` Dave Chinner
2011-01-28 18:13 ` Ric Wheeler
2011-01-28 18:13 ` Ric Wheeler
2010-11-09 20:51 ` Josef Bacik
2010-11-09 20:51 ` Josef Bacik
2010-11-15 17:05 Hole Punching V2 Josef Bacik
2010-11-15 17:05 ` [PATCH 1/6] fs: add hole punching to fallocate Josef Bacik
2010-11-15 17:05 ` Josef Bacik
2010-11-15 17:05 ` Josef Bacik
2010-11-16 11:16 ` Jan Kara
2010-11-16 11:16 ` Jan Kara
2010-11-16 11:43 ` Jan Kara
2010-11-16 11:43 ` Jan Kara
2010-11-16 12:52 ` Josef Bacik
2010-11-16 12:52 ` Josef Bacik
2010-11-16 13:14 ` Jan Kara
2010-11-16 13:14 ` Jan Kara
2010-11-17 0:22 ` Andreas Dilger
2010-11-17 0:22 ` Andreas Dilger
2010-11-17 2:11 ` Dave Chinner
2010-11-17 2:11 ` Dave Chinner
2010-11-17 2:28 ` Josef Bacik
2010-11-17 2:28 ` Josef Bacik
2010-11-17 2:34 ` Josef Bacik
2010-11-17 2:34 ` Josef Bacik
2010-11-17 9:30 ` Andreas Dilger
2010-11-17 9:30 ` Andreas Dilger
2010-11-17 9:19 ` Andreas Dilger
2010-11-17 9:19 ` Andreas Dilger
2010-11-16 12:53 ` Josef Bacik
2010-11-16 12:53 ` Josef Bacik
2010-11-18 1:46 Hole Punching V3 Josef Bacik
2010-11-18 1:46 ` [PATCH 1/6] fs: add hole punching to fallocate Josef Bacik
2010-11-18 1:46 ` Josef Bacik
2010-11-18 1:46 ` Josef Bacik
2010-11-18 23:43 ` Jan Kara
2010-11-18 23:43 ` Jan Kara
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=20101109044242.GH2715@dastard \
--to=david@fromorbit.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xfs@oss \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.