On Mon, Apr 9, 2018 at 10:51 AM, Dave Chinner <da...@fromorbit.com> wrote:
> On Sun, Apr 08, 2018 at 10:07:54AM +0800, Eryu Guan wrote:
>> On Thu, Apr 05, 2018 at 10:56:14PM +0100, fdman...@kernel.org wrote:
>> > From: Filipe Manana <fdman...@suse.com>
>> > Test that fsync operations preserve extents allocated with fallocate(2)
>> > that are placed beyond a file's size.
>> > This test is motivated by a bug found in btrfs where unwritten extents
>> > beyond the inode's i_size were not preserved after a fsync and power
>> > failure. The btrfs bug is fixed by the following patch for the linux
>> > kernel:
>> > "Btrfs: fix loss of prealloc extents past i_size after fsync log replay"
>> > Signed-off-by: Filipe Manana <fdman...@suse.com>
>> Hmm, xfs fails this test, while ext4 passes.
>> # diff -u tests/generic/483.out
>> --- tests/generic/483.out 2018-04-07 23:35:00.555555511 +0800
>> +++ /root/workspace/xfstests/results//xfs_4k_crc/generic/483.out.bad
>> 2018-04-07 23:39:48.780659707 +0800
>> @@ -6,5 +6,5 @@
>> 0: [0..511]: data
>> 1: [512..2559]: unwritten
>> File baz fiemap:
>> -0: [0..511]: data
>> -1: [512..6143]: unwritten
>> +0: [0..895]: data
>> +1: [896..6143]: unwritten
> Perfectly valid result from the test.
Still very surprising without knowing specifics about xfs (as you
>> > +# A file which already has a prealloc extent beyond its size.
>> > +# The fsync done on it is motivated by differences in the btrfs
>> > implementation
>> > +# of fsync (first fsync has different logic from subsequent fsyncs).
>> > +$XFS_IO_PROG -f -c "pwrite -S 0xf1 0 256K" \
>> > + -c "falloc -k 256K 768K" \
>> > + -c "fsync" \
>> > + $SCRATCH_MNT/baz >/dev/null
> Delayed allocation extending the file to 256k means we'll have
> speculative prealloc of data beyond 256k - it should be somewhere
> around 448k IIRC.
> Now, falloc doesn't guarantee unwritten extents are allocated - it
> just guarantees space is allocated. unwritten extents are an
> optimisation to avoid needing to zero the extents pre-allocated
> within EOF. i.e. we can quite safely allocate data extents beyond
> EOF rather than unwritten extents, and this is not a bug.
> In this case, the delalloc extent is completely allocated as written
> data, but nothing is written beyond EOF @ 256k. Hence it reports as
> a data extent, not an unwritten extent, and this is a perfectly
> valid thing to do.
>> > +# Allocate another extent beyond the size of file baz.
>> > +$XFS_IO_PROG -c "falloc -k 1M 2M"\
>> > + -c "fsync" \
>> > + $SCRATCH_MNT/baz
> You also cannot assume that two separate preallocations beyond EOF
> are going to be contiguous (i.e. it could be two separate extents.
I really don't care about that.
Just want to check that allocated space is not lost, don't care if
that space is covered by 1, 2 or more extents, or whether they are
contiguous or not.
> What you should just be checking is that there are extents allocated
> covering EOF to 3MB, not the exactly size, shape and type of extents
> are allocated.
How to do such check, for a generic test, without using fiemap?
> Dave Chinner
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html