All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: xfs@oss.sgi.com, linux-ext4@vger.kernel.org,
	Theodore Ts'o <tytso@mit.edu>, Zheng Liu <wenqing.lz@taobao.com>,
	Jie Liu <jeff.liu@oracle.com>
Subject: Re: [PATCH 0/4] xfstests: seek data/hole and hole punching improvements
Date: Wed, 6 Feb 2013 10:42:25 +0800	[thread overview]
Message-ID: <20130206024225.GA11254@gmail.com> (raw)
In-Reply-To: <511127C2.2010409@sgi.com>

On Tue, Feb 05, 2013 at 09:39:46AM -0600, Mark Tinguely wrote:
> On 01/28/13 01:32, Zheng Liu wrote:
> >Hi all,
> >
> >Here is my first try to improve seek data/hole and hole punching test
> >cases in xfstests.  The key issue in 255 and 285 is that they assume that
> >all file systems that are tested support unwritten extent preallocation.
> >Before 3.8 kernel it is correct.  But now ext4 file system has ability
> >to seek data/hole and punch a hole for a file w/o unwritten extent.  So
> >it is time to improve these test cases.
> >
> >In this patch series it calls _require_xfs_io_falloc in 255 and 285 to
> >make sure that unwritten extent is supprted by tested file system.  A
> >new argument '-t' is added into seek_sanity_test to check a file system
> >that supports seek data/hole or not.  In the mean time _require_seek_data_hole
> >is defined to be used by all tests.
> >
> >Further two new test cases are created to test seek data/hole and hole
> >punching w/o unwritten extent, which do the same thing like 255 and 285
> >except that they don't do some test cases which are related to unwritten
> >extent.
> >
> >Any comments or feedbacks are welcome.
> >
> >Thanks,
> >						- Zheng
> 
> Hi Zheng,
> 
> I wonder if reviving the idea of putting the SEEK_DATA/SEEK_HOLE
> feature into xfs_io would simplify the existing tests and future ones.
> 
> My last version of the SEEK_DATA/SEEK_HOLE xfs_io extension should be
> sightly changed to make the hole only test output to be consistent with
> the data test; namely, it should end with an EOF entry.
> 
> 	http://oss.sgi.com/archives/xfs/2012-11/msg00106.html
> 
> I know there will be some result filtering needed for holes which the C
> program based tests already provide.

Hi Mark,

Thanks for your comment.  I am fine with your idea of using xfs_io to
seek data/hole.  In next version I will try to use xfs_io to implement
_require_seek_data_hole().

Regards,
                                                - Zheng

WARNING: multiple messages have this Message-ID (diff)
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: Jie Liu <jeff.liu@oracle.com>,
	linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
	Zheng Liu <wenqing.lz@taobao.com>,
	xfs@oss.sgi.com
Subject: Re: [PATCH 0/4] xfstests: seek data/hole and hole punching improvements
Date: Wed, 6 Feb 2013 10:42:25 +0800	[thread overview]
Message-ID: <20130206024225.GA11254@gmail.com> (raw)
In-Reply-To: <511127C2.2010409@sgi.com>

On Tue, Feb 05, 2013 at 09:39:46AM -0600, Mark Tinguely wrote:
> On 01/28/13 01:32, Zheng Liu wrote:
> >Hi all,
> >
> >Here is my first try to improve seek data/hole and hole punching test
> >cases in xfstests.  The key issue in 255 and 285 is that they assume that
> >all file systems that are tested support unwritten extent preallocation.
> >Before 3.8 kernel it is correct.  But now ext4 file system has ability
> >to seek data/hole and punch a hole for a file w/o unwritten extent.  So
> >it is time to improve these test cases.
> >
> >In this patch series it calls _require_xfs_io_falloc in 255 and 285 to
> >make sure that unwritten extent is supprted by tested file system.  A
> >new argument '-t' is added into seek_sanity_test to check a file system
> >that supports seek data/hole or not.  In the mean time _require_seek_data_hole
> >is defined to be used by all tests.
> >
> >Further two new test cases are created to test seek data/hole and hole
> >punching w/o unwritten extent, which do the same thing like 255 and 285
> >except that they don't do some test cases which are related to unwritten
> >extent.
> >
> >Any comments or feedbacks are welcome.
> >
> >Thanks,
> >						- Zheng
> 
> Hi Zheng,
> 
> I wonder if reviving the idea of putting the SEEK_DATA/SEEK_HOLE
> feature into xfs_io would simplify the existing tests and future ones.
> 
> My last version of the SEEK_DATA/SEEK_HOLE xfs_io extension should be
> sightly changed to make the hole only test output to be consistent with
> the data test; namely, it should end with an EOF entry.
> 
> 	http://oss.sgi.com/archives/xfs/2012-11/msg00106.html
> 
> I know there will be some result filtering needed for holes which the C
> program based tests already provide.

Hi Mark,

Thanks for your comment.  I am fine with your idea of using xfs_io to
seek data/hole.  In next version I will try to use xfs_io to implement
_require_seek_data_hole().

Regards,
                                                - Zheng

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

  reply	other threads:[~2013-02-06  2:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-28  7:32 [PATCH 0/4] xfstests: seek data/hole and hole punching improvements Zheng Liu
2013-01-28  7:32 ` Zheng Liu
2013-01-28  7:32 ` [PATCH 1/4] xfstests: check unwritten extent preallocation in 255 Zheng Liu
2013-01-28  7:32   ` Zheng Liu
2013-01-28  7:32 ` [PATCH 2/4] xfstests: 295: test fallocate hole punching for all file systems Zheng Liu
2013-01-28  7:32   ` Zheng Liu
2013-01-28  7:32 ` [PATCH 3/4] xfstests: check llseek(2) SEEK_DATA/HOLE and unwritten extent preallocation in 285 Zheng Liu
2013-01-28  7:32   ` Zheng Liu
2013-01-28  7:32 ` [PATCH 4/4] xfstests: 296: add a seek data/hole test w/o unwritten extent Zheng Liu
2013-01-28  7:32   ` Zheng Liu
2013-02-05 15:39 ` [PATCH 0/4] xfstests: seek data/hole and hole punching improvements Mark Tinguely
2013-02-05 15:39   ` Mark Tinguely
2013-02-06  2:42   ` Zheng Liu [this message]
2013-02-06  2:42     ` Zheng Liu

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=20130206024225.GA11254@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=jeff.liu@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tinguely@sgi.com \
    --cc=tytso@mit.edu \
    --cc=wenqing.lz@taobao.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.