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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
