All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jan Kara <jack@suse.cz>, 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, cmm@us.ibm.com, cluster-devel@redhat.com,
	ocfs2-devel@oss.oracle.com
Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate
Date: Wed, 17 Nov 2010 13:11:50 +1100	[thread overview]
Message-ID: <20101117021150.GL22876@dastard> (raw)
In-Reply-To: <18ACAA85-8847-4B12-9839-F99FB6C7B3E4@dilger.ca>

On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote:
> On 2010-11-16, at 07:14, Jan Kara wrote:
> >> Yeah I went back and forth on this.  KEEP_SIZE won't change the
> >> behavior of PUNCH_HOLE since PUNCH_HOLE implicitly means keep
> >> the size.  I figured since its "mode" and not "flags" it would
> >> be ok to make either way accepted, but if you prefer PUNCH_HOLE
> >> means you have to have KEEP_SIZE set then I'm cool with that,
> >> just let me know one way or the other.
> > 
> > So we call it "mode" but speak about "flags"? Seems a bit
> > inconsistent.  I'd maybe lean a bit at the "flags" side and just
> > make sure that only one of FALLOC_FL_KEEP_SIZE,
> > FALLOC_FL_PUNCH_HOLE is set (interpreting FALLOC_FL_KEEP_SIZE as
> > allocate blocks beyond i_size). But I'm not sure what others
> > think.
> 
> IMHO, it makes more sense for consistency and "get what users
> expect" that these be treated as flags.  Some users will want
> KEEP_SIZE, but in other cases it may make sense that a hole punch
> at the end of a file should shrink the file (i.e. the opposite of
> an append).

What's wrong with ftruncate() for this?

There's plenty of open questions about the interface if we allow
hole punching to change the file size. e.g. where do we set the EOF
(offset or offset+len)?  What do we do with the rest of the blocks
that are now beyond EOF?  We weren't asked to punch them out, so do
we leave them behind? What if we are leaving written blocks beyond
EOF - does any filesystem other than XFS support that (i.e. are we
introducing different behaviour on different filesystems)?  And what
happens if the offset is beyond EOF? Do we extend the file, and if
so why wouldn't you just use ftruncate() instead?

IMO, allowing hole punching to change the file size makes it much
more complicated and hence less likely to simply do what the user
expects. It also is harder to implement and testing becomes much
more intricate. From that perspective, it does not seem desirable to
me...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jan Kara <jack@suse.cz>,
	ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org,
	xfs@oss.sgi.com, cluster-devel@redhat.com, cmm@us.ibm.com,
	Josef Bacik <josef@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/6] fs: add hole punching to fallocate
Date: Wed, 17 Nov 2010 13:11:50 +1100	[thread overview]
Message-ID: <20101117021150.GL22876@dastard> (raw)
In-Reply-To: <18ACAA85-8847-4B12-9839-F99FB6C7B3E4@dilger.ca>

On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote:
> On 2010-11-16, at 07:14, Jan Kara wrote:
> >> Yeah I went back and forth on this.  KEEP_SIZE won't change the
> >> behavior of PUNCH_HOLE since PUNCH_HOLE implicitly means keep
> >> the size.  I figured since its "mode" and not "flags" it would
> >> be ok to make either way accepted, but if you prefer PUNCH_HOLE
> >> means you have to have KEEP_SIZE set then I'm cool with that,
> >> just let me know one way or the other.
> > 
> > So we call it "mode" but speak about "flags"? Seems a bit
> > inconsistent.  I'd maybe lean a bit at the "flags" side and just
> > make sure that only one of FALLOC_FL_KEEP_SIZE,
> > FALLOC_FL_PUNCH_HOLE is set (interpreting FALLOC_FL_KEEP_SIZE as
> > allocate blocks beyond i_size). But I'm not sure what others
> > think.
> 
> IMHO, it makes more sense for consistency and "get what users
> expect" that these be treated as flags.  Some users will want
> KEEP_SIZE, but in other cases it may make sense that a hole punch
> at the end of a file should shrink the file (i.e. the opposite of
> an append).

What's wrong with ftruncate() for this?

There's plenty of open questions about the interface if we allow
hole punching to change the file size. e.g. where do we set the EOF
(offset or offset+len)?  What do we do with the rest of the blocks
that are now beyond EOF?  We weren't asked to punch them out, so do
we leave them behind? What if we are leaving written blocks beyond
EOF - does any filesystem other than XFS support that (i.e. are we
introducing different behaviour on different filesystems)?  And what
happens if the offset is beyond EOF? Do we extend the file, and if
so why wouldn't you just use ftruncate() instead?

IMO, allowing hole punching to change the file size makes it much
more complicated and hence less likely to simply do what the user
expects. It also is harder to implement and testing becomes much
more intricate. From that perspective, it does not seem desirable to
me...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jan Kara <jack@suse.cz>, 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, cmm@us.ibm.com, cluster-devel@redhat.com,
	ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/6] fs: add hole punching to fallocate
Date: Wed, 17 Nov 2010 02:12:06 -0000	[thread overview]
Message-ID: <20101117021150.GL22876@dastard> (raw)
In-Reply-To: <18ACAA85-8847-4B12-9839-F99FB6C7B3E4@dilger.ca>

On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote:
> On 2010-11-16, at 07:14, Jan Kara wrote:
> >> Yeah I went back and forth on this.  KEEP_SIZE won't change the
> >> behavior of PUNCH_HOLE since PUNCH_HOLE implicitly means keep
> >> the size.  I figured since its "mode" and not "flags" it would
> >> be ok to make either way accepted, but if you prefer PUNCH_HOLE
> >> means you have to have KEEP_SIZE set then I'm cool with that,
> >> just let me know one way or the other.
> > 
> > So we call it "mode" but speak about "flags"? Seems a bit
> > inconsistent.  I'd maybe lean a bit at the "flags" side and just
> > make sure that only one of FALLOC_FL_KEEP_SIZE,
> > FALLOC_FL_PUNCH_HOLE is set (interpreting FALLOC_FL_KEEP_SIZE as
> > allocate blocks beyond i_size). But I'm not sure what others
> > think.
> 
> IMHO, it makes more sense for consistency and "get what users
> expect" that these be treated as flags.  Some users will want
> KEEP_SIZE, but in other cases it may make sense that a hole punch
> at the end of a file should shrink the file (i.e. the opposite of
> an append).

What's wrong with ftruncate() for this?

There's plenty of open questions about the interface if we allow
hole punching to change the file size. e.g. where do we set the EOF
(offset or offset+len)?  What do we do with the rest of the blocks
that are now beyond EOF?  We weren't asked to punch them out, so do
we leave them behind? What if we are leaving written blocks beyond
EOF - does any filesystem other than XFS support that (i.e. are we
introducing different behaviour on different filesystems)?  And what
happens if the offset is beyond EOF? Do we extend the file, and if
so why wouldn't you just use ftruncate() instead?

IMO, allowing hole punching to change the file size makes it much
more complicated and hence less likely to simply do what the user
expects. It also is harder to implement and testing becomes much
more intricate. From that perspective, it does not seem desirable to
me...

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com

  reply	other threads:[~2010-11-17  2:11 UTC|newest]

Thread overview: 151+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-15 17:05 Hole Punching V2 Josef Bacik
2010-11-15 17:14 ` [Ocfs2-devel] " Josef Bacik
2010-11-15 17:05 ` Josef Bacik
2010-11-15 17:05 ` Josef Bacik
2010-11-15 17:05 ` [PATCH 1/6] fs: add hole punching to fallocate Josef Bacik
2010-11-15 17:14   ` [Ocfs2-devel] " 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     ` [Ocfs2-devel] " Jan Kara
2010-11-16 11:16     ` [Cluster-devel] " Jan Kara
2010-11-16 11:16     ` Jan Kara
2010-11-16 11:43     ` Jan Kara
2010-11-16 11:43       ` [Ocfs2-devel] " Jan Kara
2010-11-16 11:43       ` [Cluster-devel] " Jan Kara
2010-11-16 11:43       ` Jan Kara
2010-11-16 12:52       ` Josef Bacik
2010-11-16 12:53         ` [Ocfs2-devel] " Josef Bacik
2010-11-16 12:52         ` Josef Bacik
2010-11-16 13:14         ` Jan Kara
2010-11-16 13:14           ` [Ocfs2-devel] " Jan Kara
2010-11-16 13:14           ` [Cluster-devel] " Jan Kara
2010-11-16 13:14           ` Jan Kara
2010-11-17  0:22           ` Andreas Dilger
2010-11-17  0:22             ` [Ocfs2-devel] " Andreas Dilger
2010-11-17  0:22             ` Andreas Dilger
2010-11-17  2:11             ` Dave Chinner [this message]
2010-11-17  2:12               ` [Ocfs2-devel] " Dave Chinner
2010-11-17  2:11               ` Dave Chinner
2010-11-17  2:28               ` Josef Bacik
2010-11-17  2:29                 ` [Ocfs2-devel] " Josef Bacik
2010-11-17  2:28                 ` Josef Bacik
2010-11-17  2:34                 ` Josef Bacik
2010-11-17  2:35                   ` [Ocfs2-devel] " Josef Bacik
2010-11-17  2:34                   ` Josef Bacik
2010-11-17  9:30                   ` Andreas Dilger
2010-11-17  9:30                     ` [Ocfs2-devel] " Andreas Dilger
2010-11-17  9:30                     ` Andreas Dilger
2010-11-17  9:19               ` Andreas Dilger
2010-11-17  9:19                 ` [Ocfs2-devel] " Andreas Dilger
2010-11-17  9:19                 ` Andreas Dilger
2010-11-16 12:53     ` Josef Bacik
2010-11-16 12:54       ` [Ocfs2-devel] " Josef Bacik
2010-11-16 12:53       ` Josef Bacik
2010-11-15 17:05 ` [PATCH 2/6] XFS: handle hole punching via fallocate properly Josef Bacik
2010-11-15 17:14   ` [Ocfs2-devel] " Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05 ` [PATCH 3/6] Ocfs2: " Josef Bacik
2010-11-15 17:14   ` [Ocfs2-devel] " Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-16 11:50   ` Jan Kara
2010-11-16 11:50     ` [Ocfs2-devel] " Jan Kara
2010-11-16 11:50     ` [Cluster-devel] " Jan Kara
2010-11-16 11:50     ` Jan Kara
2010-11-17 23:27   ` Joel Becker
2010-11-17 23:28     ` [Ocfs2-devel] " Joel Becker
2010-11-17 23:27     ` [Cluster-devel] " Joel Becker
2010-11-17 23:27     ` Joel Becker
2010-11-15 17:05 ` [PATCH 4/6] Ext4: fail if we try to use hole punch Josef Bacik
2010-11-15 17:14   ` [Ocfs2-devel] " Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-16 11:52   ` Jan Kara
2010-11-16 11:52     ` [Ocfs2-devel] " Jan Kara
2010-11-16 11:52     ` [Cluster-devel] " Jan Kara
2010-11-16 11:52     ` Jan Kara
2010-11-16 12:25   ` Avi Kivity
2010-11-16 12:25     ` [Ocfs2-devel] " Avi Kivity
2010-11-16 12:25     ` Avi Kivity
2010-11-16 12:50     ` Josef Bacik
2010-11-16 12:50       ` [Ocfs2-devel] " Josef Bacik
2010-11-16 12:50       ` Josef Bacik
2010-11-16 13:07       ` Avi Kivity
2010-11-16 13:07         ` [Ocfs2-devel] " Avi Kivity
2010-11-16 13:07         ` Avi Kivity
2010-11-16 16:05         ` Josef Bacik
2010-11-16 16:06           ` [Ocfs2-devel] " Josef Bacik
2010-11-16 16:05           ` Josef Bacik
2010-11-16 20:47           ` Greg Freemyer
2010-11-16 20:47             ` [Ocfs2-devel] " Greg Freemyer
2010-11-16 20:47             ` Greg Freemyer
2010-11-16 20:47             ` Greg Freemyer
2010-11-16 20:47             ` Greg Freemyer
2010-11-17  3:06         ` Ted Ts'o
2010-11-17  3:06           ` [Ocfs2-devel] " Ted Ts'o
2010-11-17  3:06           ` Ted Ts'o
2010-11-17  6:31           ` Josef Bacik
2010-11-17  6:32             ` [Ocfs2-devel] " Josef Bacik
2010-11-17  6:31             ` Josef Bacik
2010-11-17  6:31             ` Josef Bacik
2010-11-17  6:31           ` Josef Bacik
2010-11-16 16:20   ` Pádraig Brady
2010-11-16 16:21     ` [Ocfs2-devel] " Pádraig Brady
2010-11-16 16:20     ` Pádraig Brady
2010-11-16 16:20     ` Pádraig Brady
2010-11-16 16:33     ` Josef Bacik
2010-11-16 16:33       ` [Ocfs2-devel] " Josef Bacik
2010-11-16 16:33       ` Josef Bacik
2010-11-16 16:33       ` Josef Bacik
2010-11-16 16:56       ` Pádraig Brady
2010-11-15 17:05 ` [PATCH 5/6] Btrfs: " Josef Bacik
2010-11-15 17:14   ` [Ocfs2-devel] " Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05 ` [PATCH 6/6] Gfs2: " Josef Bacik
2010-11-15 17:14   ` [Ocfs2-devel] " Josef Bacik
2010-11-15 17:05   ` Josef Bacik
2010-11-15 17:05   ` Josef Bacik
  -- strict thread matches above, loose matches on Subject: below --
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
2010-11-08 20:32 Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-08 20:32 ` Josef Bacik
2010-11-09  1:12 ` 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
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           ` 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

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=20101117021150.GL22876@dastard \
    --to=david@fromorbit.com \
    --cc=adilger@dilger.ca \
    --cc=cluster-devel@redhat.com \
    --cc=cmm@us.ibm.com \
    --cc=jack@suse.cz \
    --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=ocfs2-devel@oss.oracle.com \
    --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 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.