| Message ID | 1393355728-12056-6-git-send-email-lczerner@redhat.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > This is copy of xfs/242. However it's better to make it file system > specific because the range can be zeroes either directly by writing > zeroes, or converting to unwritten extent, so the actual result might > differ from file system to file system. You could say the same thing about preallocation using unwritten extents. Yet, funnily enough, we have generic tests for them because all filesystems currently use unwritten extents for preallocation and behave identically.... This test is no different - all filesystems currently use unwritten extents, and so this test should be generic because all existing filesystems *should* behave the same. When we get a filesystem that zeros rather uses unwritten extents, we can add a new *generic* test that tests for zeroed data extents rather than unwritten extents. All that we will need is a method of checking what behaviour the filesystem has and adding that to a _requires directive to ensure the correct generic fallocate tests are run... Cheers, Dave.
On Wed, 26 Feb 2014, Dave Chinner wrote: > Date: Wed, 26 Feb 2014 07:53:49 +1100 > From: Dave Chinner <david@fromorbit.com> > To: Lukas Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > This is copy of xfs/242. However it's better to make it file system > > specific because the range can be zeroes either directly by writing > > zeroes, or converting to unwritten extent, so the actual result might > > differ from file system to file system. > > You could say the same thing about preallocation using unwritten > extents. Yet, funnily enough, we have generic tests for them because > all filesystems currently use unwritten extents for preallocation > and behave identically.... > > This test is no different - all filesystems currently use unwritten > extents, and so this test should be generic because all existing > filesystems *should* behave the same. > > When we get a filesystem that zeros rather uses unwritten extents, > we can add a new *generic* test that tests for zeroed data extents > rather than unwritten extents. All that we will need is a method of > checking what behaviour the filesystem has and adding that to a > _requires directive to ensure the correct generic fallocate tests > are run... Currently xfs/242 fails on xfs for me and it does behave differently than ext4. Also I had to change to 242.out a bit because ext4 was a little different. It seems to me that it was expected that when the extent is small enough it would be overwritten by zeroes rather than converted to unwritten, but I have not looked into implementation. Btw this kind of optimization is actually something I've been thinking of as well for ext4. Rather than going though the hassle of changing extents around it might be worth in some situation to zero out. But that's an optimization I have not implemented yet. -Lukas > > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 25 Feb 2014, Lukáš Czerner wrote: > Date: Tue, 25 Feb 2014 22:01:06 +0100 (CET) > From: Lukáš Czerner <lczerner@redhat.com> > To: Dave Chinner <david@fromorbit.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > Date: Wed, 26 Feb 2014 07:53:49 +1100 > > From: Dave Chinner <david@fromorbit.com> > > To: Lukas Czerner <lczerner@redhat.com> > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > range > > > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > > This is copy of xfs/242. However it's better to make it file system > > > specific because the range can be zeroes either directly by writing > > > zeroes, or converting to unwritten extent, so the actual result might > > > differ from file system to file system. > > > > You could say the same thing about preallocation using unwritten > > extents. Yet, funnily enough, we have generic tests for them because > > all filesystems currently use unwritten extents for preallocation > > and behave identically.... > > > > This test is no different - all filesystems currently use unwritten > > extents, and so this test should be generic because all existing > > filesystems *should* behave the same. > > > > When we get a filesystem that zeros rather uses unwritten extents, > > we can add a new *generic* test that tests for zeroed data extents > > rather than unwritten extents. All that we will need is a method of > > checking what behaviour the filesystem has and adding that to a > > _requires directive to ensure the correct generic fallocate tests > > are run... > > Currently xfs/242 fails on xfs for me and it does behave differently > than ext4. Also I had to change to 242.out a bit because ext4 was > a little different. It seems to me that it was expected that when > the extent is small enough it would be overwritten by zeroes rather > than converted to unwritten, but I have not looked into > implementation. > > Btw this kind of optimization is actually something I've been > thinking of as well for ext4. Rather than going though the hassle of > changing extents around it might be worth in some situation to zero > out. But that's an optimization I have not implemented yet. Oops, I am taking it back. It's just too late and apparently I've overlooked something. -Lukas > > -Lukas > > > > > > Cheers, > > > > Dave. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On Tue, Feb 25, 2014 at 10:01:06PM +0100, Lukáš Czerner wrote: > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > Date: Wed, 26 Feb 2014 07:53:49 +1100 > > From: Dave Chinner <david@fromorbit.com> > > To: Lukas Czerner <lczerner@redhat.com> > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > range > > > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > > This is copy of xfs/242. However it's better to make it file system > > > specific because the range can be zeroes either directly by writing > > > zeroes, or converting to unwritten extent, so the actual result might > > > differ from file system to file system. > > > > You could say the same thing about preallocation using unwritten > > extents. Yet, funnily enough, we have generic tests for them because > > all filesystems currently use unwritten extents for preallocation > > and behave identically.... > > > > This test is no different - all filesystems currently use unwritten > > extents, and so this test should be generic because all existing > > filesystems *should* behave the same. > > > > When we get a filesystem that zeros rather uses unwritten extents, > > we can add a new *generic* test that tests for zeroed data extents > > rather than unwritten extents. All that we will need is a method of > > checking what behaviour the filesystem has and adding that to a > > _requires directive to ensure the correct generic fallocate tests > > are run... > > Currently xfs/242 fails on xfs for me Really? Where's the bug report? I haven't seen a failure on xfs/242 on any of my test machines for at least a year, even on 1k block size filesystems... $ sudo ./check xfs/242 FSTYP -- xfs (debug) PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb MOUNT_OPTIONS -- /dev/vdb /mnt/scratch xfs/242 1s ... 0s Ran: xfs/242 Passed all 1 tests $ > and it does behave differently than ext4. In what way? Does FALLOC_FL_ZERO_RANGE on XFS behave identically to XFS_IOC_ZERO_RANGE, or is that different too? Or you haven't tested it because you wrote this test as an ext4 specific test and so haven't run this specific test exercising the FALLOC_FL_ZERO_RANGE path in XFS? IOWs, how do you know that what you are seeing is not a bug in the ext4 (or XFS for that matter) implementation? > Also I had to change to 242.out a bit because ext4 was > a little different. It seems to me that it was expected that when > the extent is small enough it would be overwritten by zeroes rather > than converted to unwritten, but I have not looked into > implementation. The test assumes that sub-block head and tail ranges will be zeroed, and everything else will be converted to unwritten extents. i.e. a single block aligned range will get converted to unwritten, but a single unaligned block range will result in the two overlapping blocks being zeroed (because they still contain valid data). This is the same sub-block zeroing behaviour as is done for hole punching - the only difference between a hole punch and a zero range on filesystems that use unwritten extents should be that the range being operated on has unwritten extents rather a hole..... > Btw this kind of optimization is actually something I've been > thinking of as well for ext4. Rather than going though the hassle of > changing extents around it might be worth in some situation to zero > out. But that's an optimization I have not implemented yet. Exactly my point - until such optimisations are implemented, all the filesystems should be behaving the same way using unwritten extents, just like for hole punching. Hence the tests should be checking that the behaviour is the same across filesystems, just like we do for hole punching. Cheers, Dave.
On Wed, 26 Feb 2014, Dave Chinner wrote: > Date: Wed, 26 Feb 2014 08:50:11 +1100 > From: Dave Chinner <david@fromorbit.com> > To: Lukáš Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Tue, Feb 25, 2014 at 10:01:06PM +0100, Lukáš Czerner wrote: > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > > > Date: Wed, 26 Feb 2014 07:53:49 +1100 > > > From: Dave Chinner <david@fromorbit.com> > > > To: Lukas Czerner <lczerner@redhat.com> > > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > > range > > > > > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > > > This is copy of xfs/242. However it's better to make it file system > > > > specific because the range can be zeroes either directly by writing > > > > zeroes, or converting to unwritten extent, so the actual result might > > > > differ from file system to file system. > > > > > > You could say the same thing about preallocation using unwritten > > > extents. Yet, funnily enough, we have generic tests for them because > > > all filesystems currently use unwritten extents for preallocation > > > and behave identically.... > > > > > > This test is no different - all filesystems currently use unwritten > > > extents, and so this test should be generic because all existing > > > filesystems *should* behave the same. > > > > > > When we get a filesystem that zeros rather uses unwritten extents, > > > we can add a new *generic* test that tests for zeroed data extents > > > rather than unwritten extents. All that we will need is a method of > > > checking what behaviour the filesystem has and adding that to a > > > _requires directive to ensure the correct generic fallocate tests > > > are run... > > > > Currently xfs/242 fails on xfs for me > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > on any of my test machines for at least a year, even on 1k block > size filesystems... > > $ sudo ./check xfs/242 > FSTYP -- xfs (debug) > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > > xfs/242 1s ... 0s > Ran: xfs/242 > Passed all 1 tests > $ Here it is. xfs/242 fails on ppc64 with latest linus tree # uname -a Linux ibm-p740-01-lp4.rhts.eng.bos.redhat.com 3.14.0-rc4+ #1 SMP Wed Feb 26 08:59:48 EST 2014 ppc64 ppc64 ppc64 GNU/Linux # ./check xfs/242 FSTYP -- xfs (non-debug) PLATFORM -- Linux/ppc64 ibm-p740-01-lp4 3.14.0-rc4+ MKFS_OPTIONS -- -f -bsize=4096 /dev/loop1 MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/loop1 /mnt/test2 xfs/242 - output mismatch (see /root/xfstests/results//xfs/242.out.bad) --- tests/xfs/242.out 2014-02-26 05:51:16.602579462 -0500 +++ /root/xfstests/results//xfs/242.out.bad 2014-02-26 09:20:55.585396040 -0500 @@ -1,76 +1,71 @@ QA output created by 242 1. into a hole 0: [0..7]: hole -1: [8..23]: unwritten +1: [8..23]: data 2: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 ... (Run 'diff -u tests/xfs/242.out /root/xfstests/results//xfs/242.out.bad' to see the entire diff) Ran: xfs/242 Failures: xfs/242 Failed 1 of 1 tests Here is 242.out.bad QA output created by 242 1. into a hole 0: [0..7]: hole 1: [8..23]: data 2: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space 0: [0..39]: data cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space 0: [0..39]: unwritten daa100df6e6711906b61c9ab5aa16032 4. hole -> data 0: [0..7]: hole 1: [8..31]: data 2: [32..39]: hole cc63069677939f69a6e8f68cae6a6dac 5. hole -> unwritten 0: [0..7]: hole 1: [8..23]: data 2: [24..31]: unwritten 3: [32..39]: hole daa100df6e6711906b61c9ab5aa16032 6. data -> hole 0: [0..23]: data 1: [24..39]: hole 1b3779878366498b28c702ef88c4a773 7. data -> unwritten 0: [0..15]: data 1: [16..31]: unwritten 2: [32..39]: hole 1b3779878366498b28c702ef88c4a773 8. unwritten -> hole 0: [0..7]: unwritten 1: [8..23]: data 2: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 9. unwritten -> data 0: [0..15]: unwritten 1: [16..31]: data 2: [32..39]: hole cc63069677939f69a6e8f68cae6a6dac 10. hole -> data -> hole 0: [0..7]: hole 1: [8..31]: data 2: [32..39]: hole daa100df6e6711906b61c9ab5aa16032 11. data -> hole -> data 0: [0..39]: data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten 0: [0..15]: unwritten 1: [16..23]: data 2: [24..39]: unwritten daa100df6e6711906b61c9ab5aa16032 13. data -> unwritten -> data 0: [0..7]: data 1: [8..23]: unwritten 2: [24..39]: data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF 0: [0..39]: data e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 0: [0..39]: data eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole 0: [0..39]: data eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0: [0..7]: data 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd *
On Wed, 26 Feb 2014, Dave Chinner wrote: > Date: Wed, 26 Feb 2014 08:50:11 +1100 > From: Dave Chinner <david@fromorbit.com> > To: Lukáš Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Tue, Feb 25, 2014 at 10:01:06PM +0100, Lukáš Czerner wrote: > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > > > Date: Wed, 26 Feb 2014 07:53:49 +1100 > > > From: Dave Chinner <david@fromorbit.com> > > > To: Lukas Czerner <lczerner@redhat.com> > > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > > range > > > > > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > > > This is copy of xfs/242. However it's better to make it file system > > > > specific because the range can be zeroes either directly by writing > > > > zeroes, or converting to unwritten extent, so the actual result might > > > > differ from file system to file system. > > > > > > You could say the same thing about preallocation using unwritten > > > extents. Yet, funnily enough, we have generic tests for them because > > > all filesystems currently use unwritten extents for preallocation > > > and behave identically.... > > > > > > This test is no different - all filesystems currently use unwritten > > > extents, and so this test should be generic because all existing > > > filesystems *should* behave the same. > > > > > > When we get a filesystem that zeros rather uses unwritten extents, > > > we can add a new *generic* test that tests for zeroed data extents > > > rather than unwritten extents. All that we will need is a method of > > > checking what behaviour the filesystem has and adding that to a > > > _requires directive to ensure the correct generic fallocate tests > > > are run... > > > > Currently xfs/242 fails on xfs for me > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > on any of my test machines for at least a year, even on 1k block > size filesystems... > > $ sudo ./check xfs/242 > FSTYP -- xfs (debug) > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > > xfs/242 1s ... 0s > Ran: xfs/242 > Passed all 1 tests > $ Ok so once again. Yesterday was rally too late and I've misinterpreted the diff. It's not that xfs behaves differently, but rather ext4 behaves differently because we in fact have a code that will zero out entire unwritten extent if it's small enough rather than split it into unwritten and written. What we currently do not have is the zeroout of part of initialized extent on zero_range when the range to zero out is small enough. And ext4 behaves the same on the edges of the range as you describe below. Also xfs/242 fails for me on ppc64 but I've already sent that report. > > > > and it does behave differently than ext4. > > In what way? Does FALLOC_FL_ZERO_RANGE on XFS behave identically to > XFS_IOC_ZERO_RANGE, or is that different too? Or you haven't tested > it because you wrote this test as an ext4 specific test and so > haven't run this specific test exercising the FALLOC_FL_ZERO_RANGE > path in XFS? It does behave differently, but not because of zero_range code, but rather when writing into uninitialized extent which is small enough. The extent will not be split but rather converted to initialized and respective parts will be zeroed out. Btw that's actually the reason why we use _filter_hole_fiemap filtes instead of _filter_fiemap I've used in ext4/242. That said I think that both tests fs specific and fs independent have it's value so I'll create generic/242 as well by using _filter_hole_fiemap. And yes, I tested xfs with fzero and it does behave the same as XFS_IOC_ZERO_RANGE. > > IOWs, how do you know that what you are seeing is not a bug in the > ext4 (or XFS for that matter) implementation? > > > Also I had to change to 242.out a bit because ext4 was > > a little different. It seems to me that it was expected that when > > the extent is small enough it would be overwritten by zeroes rather > > than converted to unwritten, but I have not looked into > > implementation. > > The test assumes that sub-block head and tail ranges will be zeroed, > and everything else will be converted to unwritten extents. i.e. a > single block aligned range will get converted to unwritten, but a > single unaligned block range will result in the two overlapping > blocks being zeroed (because they still contain valid data). As I said above the difference in ext4 is that we're trying to avoid extent split when the extent is too small. But that's no different in punch hole testing, that's why we're using _filter_hole_fiemap filter in generic/255. > > This is the same sub-block zeroing behaviour as is done for > hole punching - the only difference between a hole punch and a zero > range on filesystems that use unwritten extents should be that the > range being operated on has unwritten extents rather a hole..... > > > Btw this kind of optimization is actually something I've been > > thinking of as well for ext4. Rather than going though the hassle of > > changing extents around it might be worth in some situation to zero > > out. But that's an optimization I have not implemented yet. > > Exactly my point - until such optimisations are implemented, all the > filesystems should be behaving the same way using unwritten extents, > just like for hole punching. Hence the tests should be checking that > the behaviour is the same across filesystems, just like we do for > hole punching. Using _filter_hole_fiemap filter in such test we would not make a difference between unwritten and written extent. However in the case of zero_range this somewhat make the test much less effective so it'll be worth having fs specific test as well as generic test I said above. Or we could actually directly inspect the data as we do in xfs/290, or generic/290 respectively. Thanks! -Lukas > > Cheers, > > Dave. >
On Wed, Feb 26, 2014 at 03:24:18PM +0100, Lukáš Czerner wrote: > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > Date: Wed, 26 Feb 2014 08:50:11 +1100 > > From: Dave Chinner <david@fromorbit.com> > > To: Lukáš Czerner <lczerner@redhat.com> > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > range > > > > On Tue, Feb 25, 2014 at 10:01:06PM +0100, Lukáš Czerner wrote: > > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > > > > > Date: Wed, 26 Feb 2014 07:53:49 +1100 > > > > From: Dave Chinner <david@fromorbit.com> > > > > To: Lukas Czerner <lczerner@redhat.com> > > > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > > > range > > > > > > > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > > > > This is copy of xfs/242. However it's better to make it file system > > > > > specific because the range can be zeroes either directly by writing > > > > > zeroes, or converting to unwritten extent, so the actual result might > > > > > differ from file system to file system. > > > > > > > > You could say the same thing about preallocation using unwritten > > > > extents. Yet, funnily enough, we have generic tests for them because > > > > all filesystems currently use unwritten extents for preallocation > > > > and behave identically.... > > > > > > > > This test is no different - all filesystems currently use unwritten > > > > extents, and so this test should be generic because all existing > > > > filesystems *should* behave the same. > > > > > > > > When we get a filesystem that zeros rather uses unwritten extents, > > > > we can add a new *generic* test that tests for zeroed data extents > > > > rather than unwritten extents. All that we will need is a method of > > > > checking what behaviour the filesystem has and adding that to a > > > > _requires directive to ensure the correct generic fallocate tests > > > > are run... > > > > > > Currently xfs/242 fails on xfs for me > > > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > > on any of my test machines for at least a year, even on 1k block > > size filesystems... > > > > $ sudo ./check xfs/242 > > FSTYP -- xfs (debug) > > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb > > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > > > > xfs/242 1s ... 0s > > Ran: xfs/242 > > Passed all 1 tests > > $ > > Here it is. > > xfs/242 fails on ppc64 with latest linus tree OK, that's a different kettle of fish. It's using 64k pages, right? > # uname -a > Linux ibm-p740-01-lp4.rhts.eng.bos.redhat.com 3.14.0-rc4+ #1 SMP Wed > Feb 26 08:59:48 EST 2014 ppc64 ppc64 ppc64 GNU/Linux > > # ./check xfs/242 > FSTYP -- xfs (non-debug) > PLATFORM -- Linux/ppc64 ibm-p740-01-lp4 3.14.0-rc4+ > MKFS_OPTIONS -- -f -bsize=4096 /dev/loop1 > MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/loop1 /mnt/test2 > > xfs/242 - output mismatch (see /root/xfstests/results//xfs/242.out.bad) > --- tests/xfs/242.out 2014-02-26 05:51:16.602579462 -0500 > +++ /root/xfstests/results//xfs/242.out.bad 2014-02-26 09:20:55.585396040 -0500 > @@ -1,76 +1,71 @@ > QA output created by 242 > 1. into a hole > 0: [0..7]: hole > -1: [8..23]: unwritten > +1: [8..23]: data > 2: [24..39]: hole > daa100df6e6711906b61c9ab5aa16032 So the data is correct, but the range got zeroes written to it rather than an unwritten extent. > (Run 'diff -u tests/xfs/242.out /root/xfstests/results//xfs/242.out.bad' to see the entire diff) > Ran: xfs/242 > Failures: xfs/242 > Failed 1 of 1 tests > > > Here is 242.out.bad The diff would have been better. /me goes off to diff the output Yeah, ok, the data in all the files is correct - the md5sums all match. What's different? Just about all unwritten extents are now written (i.e. data) or contain some portion of written extents. So, ZERO_RANGE has the following size threshold for converting blocks to unwritten extents vs just zeroing them: granularity = max_t(uint, 1 << mp->m_sb.sb_blocklog, PAGE_CACHE_SIZE); So if this is a 64k page size machine, it's going to have different extent layout compared to a 4k page size machine. The file data will still be the same, the difference will be zeroed blocks instead of unwritten blocks, and that's exactly what we see. IOWs, the result in terms of data the application sees is correct, just the extent layout representing that zeroed data is different. Cheers, Dave.
On Wed, Feb 26, 2014 at 03:58:36PM +0100, Lukáš Czerner wrote: > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > Currently xfs/242 fails on xfs for me > > > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > > on any of my test machines for at least a year, even on 1k block > > size filesystems... > > > > $ sudo ./check xfs/242 > > FSTYP -- xfs (debug) > > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb > > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > > > > xfs/242 1s ... 0s > > Ran: xfs/242 > > Passed all 1 tests > > $ > > Ok so once again. Yesterday was rally too late and I've > misinterpreted the diff. It's not that xfs behaves differently, but > rather ext4 behaves differently because we in fact have a code that > will zero out entire unwritten extent if it's small enough rather > than split it into unwritten and written. Yes, we've come across this before, and there are several solutions. this one is used in tests/generic/285: # Disable extent zeroing for ext4 as that change where holes ar created if [ "$FSTYP" = "ext4" ]; then DEV=`basename $TEST_DEV` echo 0 >/sys/fs/ext4/$DEV/extent_max_zeroout_kb fi > > > and it does behave differently than ext4. > > > > In what way? Does FALLOC_FL_ZERO_RANGE on XFS behave identically to > > XFS_IOC_ZERO_RANGE, or is that different too? Or you haven't tested > > it because you wrote this test as an ext4 specific test and so > > haven't run this specific test exercising the FALLOC_FL_ZERO_RANGE > > path in XFS? > > It does behave differently, but not because of zero_range code, but > rather when writing into uninitialized extent which is small enough. > The extent will not be split but rather converted to initialized and > respective parts will be zeroed out. > > Btw that's actually the reason why we use > > _filter_hole_fiemap > > filtes instead of > > _filter_fiemap > > I've used in ext4/242. Sure, but even so I think we might do better just to use the above zeroout tune and be explicit in what we expect to happen w.r.t. data vs holes... > > That said I think that both tests fs specific and fs independent > have it's value so I'll create generic/242 as well by using > _filter_hole_fiemap. Just use the first unused generic test number - trying to keep test numbers the same across different subdirs is just going to cause confusion.... > > hole punching - the only difference between a hole punch and a zero > > range on filesystems that use unwritten extents should be that the > > range being operated on has unwritten extents rather a hole..... > > > > > Btw this kind of optimization is actually something I've been > > > thinking of as well for ext4. Rather than going though the hassle of > > > changing extents around it might be worth in some situation to zero > > > out. But that's an optimization I have not implemented yet. > > > > Exactly my point - until such optimisations are implemented, all the > > filesystems should be behaving the same way using unwritten extents, > > just like for hole punching. Hence the tests should be checking that > > the behaviour is the same across filesystems, just like we do for > > hole punching. > > Using _filter_hole_fiemap filter in such test we would not make a > difference between unwritten and written extent. However in the case > of zero_range this somewhat make the test much less effective so > it'll be worth having fs specific test as well as generic test I > said above. > > Or we could actually directly inspect the data as we do in xfs/290, or > generic/290 respectively. The md5sum does the data inspection for us. The whole point of hole punch and zero range and so one is that they are extent manipulation operations. If we don't check that extents have been manipulated correctly, then we aren't testing that the key behaviour the filesystems are supposed to display for those operations.... Cheers, Dave.
On Thu, 27 Feb 2014, Dave Chinner wrote: > Date: Thu, 27 Feb 2014 09:17:57 +1100 > From: Dave Chinner <david@fromorbit.com> > To: Lukáš Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Wed, Feb 26, 2014 at 03:58:36PM +0100, Lukáš Czerner wrote: > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > > Currently xfs/242 fails on xfs for me > > > > > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > > > on any of my test machines for at least a year, even on 1k block > > > size filesystems... > > > > > > $ sudo ./check xfs/242 > > > FSTYP -- xfs (debug) > > > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > > > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb > > > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > > > > > > xfs/242 1s ... 0s > > > Ran: xfs/242 > > > Passed all 1 tests > > > $ > > > > Ok so once again. Yesterday was rally too late and I've > > misinterpreted the diff. It's not that xfs behaves differently, but > > rather ext4 behaves differently because we in fact have a code that > > will zero out entire unwritten extent if it's small enough rather > > than split it into unwritten and written. > > Yes, we've come across this before, and there are several solutions. > this one is used in tests/generic/285: > > # Disable extent zeroing for ext4 as that change where holes ar created > if [ "$FSTYP" = "ext4" ]; then > DEV=`basename $TEST_DEV` > echo 0 >/sys/fs/ext4/$DEV/extent_max_zeroout_kb > fi When testing SEEK_DATA, SEEK_HOLE this is probably just fine. But when it comes to actually changing the extent tree and checking the result I would rather not disable this because it is the default and we want to test that code as well. > > > > > and it does behave differently than ext4. > > > > > > In what way? Does FALLOC_FL_ZERO_RANGE on XFS behave identically to > > > XFS_IOC_ZERO_RANGE, or is that different too? Or you haven't tested > > > it because you wrote this test as an ext4 specific test and so > > > haven't run this specific test exercising the FALLOC_FL_ZERO_RANGE > > > path in XFS? > > > > It does behave differently, but not because of zero_range code, but > > rather when writing into uninitialized extent which is small enough. > > The extent will not be split but rather converted to initialized and > > respective parts will be zeroed out. > > > > Btw that's actually the reason why we use > > > > _filter_hole_fiemap > > > > filtes instead of > > > > _filter_fiemap > > > > I've used in ext4/242. > > Sure, but even so I think we might do better just to use the above > zeroout tune and be explicit in what we expect to happen w.r.t. data > vs holes... > > > > > That said I think that both tests fs specific and fs independent > > have it's value so I'll create generic/242 as well by using > > _filter_hole_fiemap. > > Just use the first unused generic test number - trying to keep test > numbers the same across different subdirs is just going to cause > confusion.... Ok. Thanks! -Lukas > > > > hole punching - the only difference between a hole punch and a zero > > > range on filesystems that use unwritten extents should be that the > > > range being operated on has unwritten extents rather a hole..... > > > > > > > Btw this kind of optimization is actually something I've been > > > > thinking of as well for ext4. Rather than going though the hassle of > > > > changing extents around it might be worth in some situation to zero > > > > out. But that's an optimization I have not implemented yet. > > > > > > Exactly my point - until such optimisations are implemented, all the > > > filesystems should be behaving the same way using unwritten extents, > > > just like for hole punching. Hence the tests should be checking that > > > the behaviour is the same across filesystems, just like we do for > > > hole punching. > > > > Using _filter_hole_fiemap filter in such test we would not make a > > difference between unwritten and written extent. However in the case > > of zero_range this somewhat make the test much less effective so > > it'll be worth having fs specific test as well as generic test I > > said above. > > > > Or we could actually directly inspect the data as we do in xfs/290, or > > generic/290 respectively. > > The md5sum does the data inspection for us. The whole point of > hole punch and zero range and so one is that they are extent > manipulation operations. If we don't check that extents have been > manipulated correctly, then we aren't testing that the key behaviour > the filesystems are supposed to display for those operations.... > > Cheers, > > Dave. >
On Thu, 27 Feb 2014, Dave Chinner wrote: > Date: Thu, 27 Feb 2014 09:01:06 +1100 > From: Dave Chinner <david@fromorbit.com> > To: Lukáš Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Wed, Feb 26, 2014 at 03:24:18PM +0100, Lukáš Czerner wrote: > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > > > Date: Wed, 26 Feb 2014 08:50:11 +1100 > > > From: Dave Chinner <david@fromorbit.com> > > > To: Lukáš Czerner <lczerner@redhat.com> > > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > > range > > > > > > On Tue, Feb 25, 2014 at 10:01:06PM +0100, Lukáš Czerner wrote: > > > > On Wed, 26 Feb 2014, Dave Chinner wrote: > > > > > > > > > Date: Wed, 26 Feb 2014 07:53:49 +1100 > > > > > From: Dave Chinner <david@fromorbit.com> > > > > > To: Lukas Czerner <lczerner@redhat.com> > > > > > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > > > > > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > > > > > range > > > > > > > > > > On Tue, Feb 25, 2014 at 08:15:28PM +0100, Lukas Czerner wrote: > > > > > > This is copy of xfs/242. However it's better to make it file system > > > > > > specific because the range can be zeroes either directly by writing > > > > > > zeroes, or converting to unwritten extent, so the actual result might > > > > > > differ from file system to file system. > > > > > > > > > > You could say the same thing about preallocation using unwritten > > > > > extents. Yet, funnily enough, we have generic tests for them because > > > > > all filesystems currently use unwritten extents for preallocation > > > > > and behave identically.... > > > > > > > > > > This test is no different - all filesystems currently use unwritten > > > > > extents, and so this test should be generic because all existing > > > > > filesystems *should* behave the same. > > > > > > > > > > When we get a filesystem that zeros rather uses unwritten extents, > > > > > we can add a new *generic* test that tests for zeroed data extents > > > > > rather than unwritten extents. All that we will need is a method of > > > > > checking what behaviour the filesystem has and adding that to a > > > > > _requires directive to ensure the correct generic fallocate tests > > > > > are run... > > > > > > > > Currently xfs/242 fails on xfs for me > > > > > > Really? Where's the bug report? I haven't seen a failure on xfs/242 > > > on any of my test machines for at least a year, even on 1k block > > > size filesystems... > > > > > > $ sudo ./check xfs/242 > > > FSTYP -- xfs (debug) > > > PLATFORM -- Linux/x86_64 test2 3.14.0-rc3-dgc+ > > > MKFS_OPTIONS -- -f -bsize=4096 /dev/vdb > > > MOUNT_OPTIONS -- /dev/vdb /mnt/scratch > > > > > > xfs/242 1s ... 0s > > > Ran: xfs/242 > > > Passed all 1 tests > > > $ > > > > Here it is. > > > > xfs/242 fails on ppc64 with latest linus tree > > OK, that's a different kettle of fish. It's using 64k pages, right? 64k pages, yes. > > > # uname -a > > Linux ibm-p740-01-lp4.rhts.eng.bos.redhat.com 3.14.0-rc4+ #1 SMP Wed > > Feb 26 08:59:48 EST 2014 ppc64 ppc64 ppc64 GNU/Linux > > > > # ./check xfs/242 > > FSTYP -- xfs (non-debug) > > PLATFORM -- Linux/ppc64 ibm-p740-01-lp4 3.14.0-rc4+ > > MKFS_OPTIONS -- -f -bsize=4096 /dev/loop1 > > MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/loop1 /mnt/test2 > > > > xfs/242 - output mismatch (see /root/xfstests/results//xfs/242.out.bad) > > --- tests/xfs/242.out 2014-02-26 05:51:16.602579462 -0500 > > +++ /root/xfstests/results//xfs/242.out.bad 2014-02-26 09:20:55.585396040 -0500 > > @@ -1,76 +1,71 @@ > > QA output created by 242 > > 1. into a hole > > 0: [0..7]: hole > > -1: [8..23]: unwritten > > +1: [8..23]: data > > 2: [24..39]: hole > > daa100df6e6711906b61c9ab5aa16032 > > So the data is correct, but the range got zeroes written to it > rather than an unwritten extent. > > > (Run 'diff -u tests/xfs/242.out /root/xfstests/results//xfs/242.out.bad' to see the entire diff) > > Ran: xfs/242 > > Failures: xfs/242 > > Failed 1 of 1 tests > > > > > > Here is 242.out.bad > > The diff would have been better. > > /me goes off to diff the output > > Yeah, ok, the data in all the files is correct - the md5sums all > match. What's different? Just about all unwritten extents are now > written (i.e. data) or contain some portion of written extents. > > So, ZERO_RANGE has the following size threshold for converting > blocks to unwritten extents vs just zeroing them: > > granularity = max_t(uint, 1 << mp->m_sb.sb_blocklog, PAGE_CACHE_SIZE); > > So if this is a 64k page size machine, it's going to have different > extent layout compared to a 4k page size machine. The file data will > still be the same, the difference will be zeroed blocks instead of > unwritten blocks, and that's exactly what we see. > > IOWs, the result in terms of data the application sees is correct, > just the extent layout representing that zeroed data is different. Ok, so that's yet another difference between xfs and ext4 code which makes having generic test even more complicated. So as I said before I'll make the generic test (using _filter_hole_fiemap) and then ext4 specific test as well to really make sure that the extent manipulation is right. Thanks! -Lukas > > Cheers, > > Dave. >
On Thu, Feb 27, 2014 at 01:03:09PM +0100, Lukáš Czerner wrote: > On Thu, 27 Feb 2014, Dave Chinner wrote: > > > xfs/242 fails on ppc64 with latest linus tree > > > > OK, that's a different kettle of fish. It's using 64k pages, right? > > 64k pages, yes. .... > > Yeah, ok, the data in all the files is correct - the md5sums all > > match. What's different? Just about all unwritten extents are now > > written (i.e. data) or contain some portion of written extents. > > > > So, ZERO_RANGE has the following size threshold for converting > > blocks to unwritten extents vs just zeroing them: > > > > granularity = max_t(uint, 1 << mp->m_sb.sb_blocklog, PAGE_CACHE_SIZE); > > > > So if this is a 64k page size machine, it's going to have different > > extent layout compared to a 4k page size machine. The file data will > > still be the same, the difference will be zeroed blocks instead of > > unwritten blocks, and that's exactly what we see. > > > > IOWs, the result in terms of data the application sees is correct, > > just the extent layout representing that zeroed data is different. > > Ok, so that's yet another difference between xfs and ext4 code which > makes having generic test even more complicated. It actually makes the need for a generic test more important. A generic test should handle the differences between block/page size behaviours - the issue is that xfs/242 was written and tested on 4k page machines, not 64k page machines. We've already got the "multiple" code in _generic_test_punch to increase the size of the regions being worked on, so the simple fix here is to increase the sizes so that 64k page and 4k page behaviour is the same and results in the same extent layout. This is the normal way tests evolve as people run them on different hardware and configurations.... > So as I said before > I'll make the generic test (using _filter_hole_fiemap) and then ext4 > specific test as well to really make sure that the extent > manipulation is right. Which ignores the fact that if you turn off zeroout on ext4 then a generic test can also determine that the extent manipulation is correct. I really don't see the need for an ext4 specific test here... Cheers, Dave.
On Fri, 28 Feb 2014, Dave Chinner wrote: > Date: Fri, 28 Feb 2014 06:35:33 +1100 > From: Dave Chinner <david@fromorbit.com> > To: Lukáš Czerner <lczerner@redhat.com> > Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com > Subject: Re: [PATCH 6/6] ext4/242: Add ext4 specific test for fallocate zero > range > > On Thu, Feb 27, 2014 at 01:03:09PM +0100, Lukáš Czerner wrote: > > On Thu, 27 Feb 2014, Dave Chinner wrote: > > > > xfs/242 fails on ppc64 with latest linus tree > > > > > > OK, that's a different kettle of fish. It's using 64k pages, right? > > > > 64k pages, yes. > .... > > > Yeah, ok, the data in all the files is correct - the md5sums all > > > match. What's different? Just about all unwritten extents are now > > > written (i.e. data) or contain some portion of written extents. > > > > > > So, ZERO_RANGE has the following size threshold for converting > > > blocks to unwritten extents vs just zeroing them: > > > > > > granularity = max_t(uint, 1 << mp->m_sb.sb_blocklog, PAGE_CACHE_SIZE); > > > > > > So if this is a 64k page size machine, it's going to have different > > > extent layout compared to a 4k page size machine. The file data will > > > still be the same, the difference will be zeroed blocks instead of > > > unwritten blocks, and that's exactly what we see. > > > > > > IOWs, the result in terms of data the application sees is correct, > > > just the extent layout representing that zeroed data is different. > > > > Ok, so that's yet another difference between xfs and ext4 code which > > makes having generic test even more complicated. > > It actually makes the need for a generic test more important. A > generic test should handle the differences between block/page size > behaviours - the issue is that xfs/242 was written and tested on 4k > page machines, not 64k page machines. > > We've already got the "multiple" code in _generic_test_punch to > increase the size of the regions being worked on, so the simple fix > here is to increase the sizes so that 64k page and 4k page behaviour > is the same and results in the same extent layout. This is the > normal way tests evolve as people run them on different hardware and > configurations.... > > > So as I said before > > I'll make the generic test (using _filter_hole_fiemap) and then ext4 > > specific test as well to really make sure that the extent > > manipulation is right. > > Which ignores the fact that if you turn off zeroout on ext4 then a > generic test can also determine that the extent manipulation is > correct. I really don't see the need for an ext4 specific test > here... I disagree, you assume that there is not a problem with the zeroout code. And if there is, then the test would not be able to catch that. And yes, bug in the zeroout code might affect zero range as well even though we do not normally do zeroout on zero range except block unaligned edges of the range. Also ext4 does not need different testing for different page sizes. That said I usually do ppc64 testing to test the operations with granularity smaller than page size (sub page size zero out etc..). With your proposal this goes away because we would actually test the operation on larger extents - that's not helpful at all. -Lukas > > Cheers, > > Dave. >
diff --git a/tests/ext4/242 b/tests/ext4/242 new file mode 100755 index 0000000..f34036c --- /dev/null +++ b/tests/ext4/242 @@ -0,0 +1,63 @@ +#! /bin/bash +# FS QA Test No. 242 +# +# Test fallocate FALLOC_FL_ZERO_RANGE +# +#----------------------------------------------------------------------- +# Copyright (c) 2010 Red Hat. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it would be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +# +#----------------------------------------------------------------------- +# + +seq=`basename $0` +seqres=$RESULT_DIR/$seq +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! + +_cleanup() +{ + rm -f $tmp.* +} + +trap "_cleanup ; exit \$status" 0 1 2 3 15 + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter +. ./common/punch + +# real QA test starts here +_supported_fs ext4 +_supported_os Linux +_require_xfs_io_falloc_zero + +_test_io_zero() +{ + $XFS_IO_PROG -c "fzero help" 2>&1 | \ + grep 'command "zero" not found' > /dev/null + echo $? +} + +[ $(_test_io_zero) -eq 0 ] && _notrun "fzero command not supported" + +testfile=$TEST_DIR/242.$$ + +_test_generic_punch falloc fzero fzero fiemap _filter_fiemap $testfile + +status=0 ; exit diff --git a/tests/ext4/242.out b/tests/ext4/242.out new file mode 100644 index 0000000..3b80b4d --- /dev/null +++ b/tests/ext4/242.out @@ -0,0 +1,84 @@ +QA output created by 242 + 1. into a hole +0: [0..7]: hole +1: [8..23]: unwritten +2: [24..39]: hole +daa100df6e6711906b61c9ab5aa16032 + 2. into allocated space +0: [0..7]: data +1: [8..23]: unwritten +2: [24..39]: data +cc58a7417c2d7763adc45b6fcd3fa024 + 3. into unwritten space +0: [0..39]: unwritten +daa100df6e6711906b61c9ab5aa16032 + 4. hole -> data +0: [0..7]: hole +1: [8..23]: unwritten +2: [24..31]: data +3: [32..39]: hole +cc63069677939f69a6e8f68cae6a6dac + 5. hole -> unwritten +0: [0..7]: hole +1: [8..31]: unwritten +2: [32..39]: hole +daa100df6e6711906b61c9ab5aa16032 + 6. data -> hole +0: [0..7]: data +1: [8..23]: unwritten +2: [24..39]: hole +1b3779878366498b28c702ef88c4a773 + 7. data -> unwritten +0: [0..7]: data +1: [8..31]: unwritten +2: [32..39]: hole +1b3779878366498b28c702ef88c4a773 + 8. unwritten -> hole +0: [0..23]: unwritten +1: [24..39]: hole +daa100df6e6711906b61c9ab5aa16032 + 9. unwritten -> data +0: [0..23]: unwritten +1: [24..31]: data +2: [32..39]: hole +cc63069677939f69a6e8f68cae6a6dac + 10. hole -> data -> hole +0: [0..7]: hole +1: [8..31]: unwritten +2: [32..39]: hole +daa100df6e6711906b61c9ab5aa16032 + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: unwritten +2: [32..39]: data +f6aeca13ec49e5b266cd1c913cd726e3 + 12. unwritten -> data -> unwritten +0: [0..7]: data +1: [8..31]: unwritten +2: [32..39]: data +daa100df6e6711906b61c9ab5aa16032 + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: unwritten +2: [32..39]: data +f6aeca13ec49e5b266cd1c913cd726e3 + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: unwritten +e1f024eedd27ea6b1c3e9b841c850404 + 15. data -> hole @ 0 +0: [0..15]: unwritten +1: [16..39]: data +eecb7aa303d121835de05028751d301c + 16. data -> cache cold ->hole +0: [0..15]: unwritten +1: [16..39]: data +eecb7aa303d121835de05028751d301c + 17. data -> hole in single block file +0: [0..7]: data +0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd +* +0000200 0000 0000 0000 0000 0000 0000 0000 0000 +* +0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd +* diff --git a/tests/ext4/group b/tests/ext4/group index 7e1a68b..c8b47cc 100644 --- a/tests/ext4/group +++ b/tests/ext4/group @@ -3,6 +3,7 @@ # - do not start group names with a digit # - comment line before each group is "new" description # +242 auto prealloc quick 271 auto rw quick 301 aio dangerous ioctl rw stress 302 aio dangerous ioctl rw stress
This is copy of xfs/242. However it's better to make it file system specific because the range can be zeroes either directly by writing zeroes, or converting to unwritten extent, so the actual result might differ from file system to file system. Signed-off-by: Lukas Czerner <lczerner@redhat.com> --- tests/ext4/242 | 63 ++++++++++++++++++++++++++++++++++++++++ tests/ext4/242.out | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/ext4/group | 1 + 3 files changed, 148 insertions(+) create mode 100755 tests/ext4/242 create mode 100644 tests/ext4/242.out