[Top] [All Lists]

Re: [PATCH 0/4] xfstests: seek data/hole and hole punching improvements

To: Zheng Liu <gnehzuil.liu@xxxxxxxxx>
Subject: Re: [PATCH 0/4] xfstests: seek data/hole and hole punching improvements
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Tue, 05 Feb 2013 09:39:46 -0600
Cc: xfs@xxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, Theodore Ts'o <tytso@xxxxxxx>, Zheng Liu <wenqing.lz@xxxxxxxxxx>, Jie Liu <jeff.liu@xxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1359358371-21411-1-git-send-email-wenqing.lz@xxxxxxxxxx>
References: <1359358371-21411-1-git-send-email-wenqing.lz@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
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

Any comments or feedbacks are welcome.

                                                - 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.


I know there will be some result filtering needed for holes which the C
program based tests already provide.

Just a thought.


<Prev in Thread] Current Thread [Next in Thread>