lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <511127C2.2010409@sgi.com>
Date:	Tue, 05 Feb 2013 09:39:46 -0600
From:	Mark Tinguely <tinguely@....com>
To:	Zheng Liu <gnehzuil.liu@...il.com>
CC:	xfs@....sgi.com, linux-ext4@...r.kernel.org,
	Theodore Ts'o <tytso@....edu>,
	Zheng Liu <wenqing.lz@...bao.com>,
	Jie Liu <jeff.liu@...cle.com>
Subject: Re: [PATCH 0/4] xfstests: seek data/hole and hole punching improvements

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.

Just a thought.

--Mark.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ