On Tue, Jan 11, 2011 at 04:30:07PM -0500, Ted Ts'o wrote:
On Tue, Jan 11, 2011 at 04:13:42PM -0500, Lawrence Greenfield wrote:
IOWs, all they want to do is avoid the unwritten extent conversion
overhead. Time has shown that a bad security/performance tradeoff
decision was made 13 years
On Tue, Jan 11, 2011 at 04:13:42PM -0500, Lawrence Greenfield wrote:
On Tue, Nov 9, 2010 at 6:40 PM, Dave Chinner da...@fromorbit.com wrote:
The historical reason for such behaviour existing in XFS was that in
1997 the CPU and IO latency cost of unwritten extent conversion was
significant,
On Wed 17-11-10 20:46:15, Josef Bacik wrote:
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add
FALLOC_FL_PUNCH_HOLE
to fallocate()
On 2010-11-16, at 20:11, Dave Chinner wrote:
On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote:
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
On 2010-11-16, at 20:34, Josef Bacik wrote:
FWIW I agree with Dave, the only question at this point is do we force users
to specify KEEP_SIZE with PUNCH_HOLE? On one hand it makes the interface a
bit more consistent, on the other hand it makes the documentation a little
weird
We have
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
to fallocate() since it already looks like the normal fallocate()
On Tue 16-11-10 12:16:11, Jan Kara wrote:
On Mon 15-11-10 12:05:18, Josef Bacik wrote:
diff --git a/fs/open.c b/fs/open.c
index 4197b9e..ab8dedf 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -223,7 +223,7 @@ int do_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
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
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
On Wed, Nov 17, 2010 at 01:11:50PM +1100, Dave Chinner wrote:
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
On Tue, Nov 16, 2010 at 09:28:14PM -0500, Josef Bacik wrote:
On Wed, Nov 17, 2010 at 01:11:50PM +1100, Dave Chinner wrote:
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
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
to fallocate() since it already looks like the normal fallocate()
On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
On Mon, Nov 08, 2010 at 03:32:02PM -0500, Josef Bacik wrote:
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way
to
get to this
On Tue, Nov 09, 2010 at 03:42:42PM +1100, Dave Chinner wrote:
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)
On Tue 09-11-10 16:41:47, Ted Ts'o wrote:
On Tue, Nov 09, 2010 at 03:42:42PM +1100, Dave Chinner wrote:
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
On Tue, Nov 09, 2010 at 04:41:47PM -0500, Ted Ts'o wrote:
On Tue, Nov 09, 2010 at 03:42:42PM +1100, Dave Chinner wrote:
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
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
to fallocate() since it already looks like the normal fallocate()
On Mon, Nov 08, 2010 at 03:32:02PM -0500, Josef Bacik wrote:
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add
FALLOC_FL_PUNCH_HOLE
On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
On Mon, Nov 08, 2010 at 03:32:02PM -0500, Josef Bacik wrote:
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way
to
get to this
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
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
21 matches
Mail list logo
