All of lore.kernel.org
 help / color / mirror / Atom feed
From: tm@tao.ma
To: "Dave Chinner" <david@fromorbit.com>
Cc: "Tao Ma" <tm@tao.ma>, "Christoph Hellwig" <hch@infradead.org>,
	xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: XFS status update for January 2011
Date: Mon, 14 Feb 2011 08:20:18 -0700	[thread overview]
Message-ID: <04650f485d5814ddfe6893a3a7c8429b.squirrel@box585.bluehost.com> (raw)
In-Reply-To: <20110214120237.GB13052@dastard>

Hi Dave,
> On Mon, Feb 14, 2011 at 10:17:26AM +0800, Tao Ma wrote:
>> Hi Christoph,
>> On 02/14/2011 02:42 AM, Christoph Hellwig wrote:
>> >On the 4th of January we saw the release of Linux 2.6.37, which
>> contains a
>> >large XFS update:
>> >
>> >     67 files changed, 1424 insertions(+), 1524 deletions(-)
>> >
>> >User visible changes are the new XFS_IOC_ZERO_RANGE ioctl which allows
>> >to convert already allocated space into unwritten extents that return
>> >zeros on a read,
>> would you mind describing some scenario that this ioctl can be used. I
>> am
>> just wondering whether ocfs2 can implement it as well.
>
> Zeroing a file without doing IO or having to punch out the blocks
> already allocated to the file.
>
> In this case, we had a couple of different people in cloud storage
> land asking for such functionality to optimise record deletion
> be avoiding disruption of their preallocated file layouts as a
> punch-then-preallocate operation does.
Thanks for the info. yeah, ocfs2 is also used to host images in some cloud
computing environment. So It looks helpful for us too.
>
> If you you have some kind of use for it in ocfs2, then implementing
> the XFS ioctl is not the correct thing to do - using the fallocate
> patch I've had sitting around (since about 15min after creating the
> XFS ioctl) is most likely the right way to proceed....
yeah, Josef has added the punching hole in fallocate, so I guess another
parameter for keeping the blocks during hole punching should be enough for
us. :)

Regards,
Tao


WARNING: multiple messages have this Message-ID (diff)
From: tm@tao.ma
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, Tao Ma <tm@tao.ma>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: XFS status update for January 2011
Date: Mon, 14 Feb 2011 08:20:18 -0700	[thread overview]
Message-ID: <04650f485d5814ddfe6893a3a7c8429b.squirrel@box585.bluehost.com> (raw)
In-Reply-To: <20110214120237.GB13052@dastard>

Hi Dave,
> On Mon, Feb 14, 2011 at 10:17:26AM +0800, Tao Ma wrote:
>> Hi Christoph,
>> On 02/14/2011 02:42 AM, Christoph Hellwig wrote:
>> >On the 4th of January we saw the release of Linux 2.6.37, which
>> contains a
>> >large XFS update:
>> >
>> >     67 files changed, 1424 insertions(+), 1524 deletions(-)
>> >
>> >User visible changes are the new XFS_IOC_ZERO_RANGE ioctl which allows
>> >to convert already allocated space into unwritten extents that return
>> >zeros on a read,
>> would you mind describing some scenario that this ioctl can be used. I
>> am
>> just wondering whether ocfs2 can implement it as well.
>
> Zeroing a file without doing IO or having to punch out the blocks
> already allocated to the file.
>
> In this case, we had a couple of different people in cloud storage
> land asking for such functionality to optimise record deletion
> be avoiding disruption of their preallocated file layouts as a
> punch-then-preallocate operation does.
Thanks for the info. yeah, ocfs2 is also used to host images in some cloud
computing environment. So It looks helpful for us too.
>
> If you you have some kind of use for it in ocfs2, then implementing
> the XFS ioctl is not the correct thing to do - using the fallocate
> patch I've had sitting around (since about 15min after creating the
> XFS ioctl) is most likely the right way to proceed....
yeah, Josef has added the punching hole in fallocate, so I guess another
parameter for keeping the blocks during hole punching should be enough for
us. :)

Regards,
Tao

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

  reply	other threads:[~2011-02-14 15:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-13 18:42 XFS status update for January 2011 Christoph Hellwig
2011-02-13 18:42 ` Christoph Hellwig
2011-02-14  2:17 ` Tao Ma
2011-02-14  2:17   ` Tao Ma
2011-02-14 12:02   ` Dave Chinner
2011-02-14 12:02     ` Dave Chinner
2011-02-14 15:20     ` tm [this message]
2011-02-14 15:20       ` tm
2011-02-14 23:55       ` Dave Chinner
2011-02-14 23:55         ` Dave Chinner
2011-02-15  2:01         ` Tao Ma
2011-02-15  2:01           ` Tao Ma

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=04650f485d5814ddfe6893a3a7c8429b.squirrel@box585.bluehost.com \
    --to=tm@tao.ma \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.