generic/098: update test for truncating a file into the middle of a hole

This updates generic/098 by adding a sync option, i.e. 'sync' after
the second write, and with btrfs's NO_HOLES, we could still get
wrong isize after remount.

This gets fixed by the patch

'Btrfs: fix truncate down when no_holes feature is enabled'

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This commit is contained in:
Liu Bo
2016-11-16 11:17:03 -08:00
committed by Eryu Guan
parent 9c5a3fa344
commit 775e2d0c03
2 changed files with 45 additions and 17 deletions
+35 -17
View File
@@ -64,27 +64,45 @@ rm -f $seqres.full
_scratch_mkfs >>$seqres.full 2>&1
_scratch_mount
# Create our test file with some data and durably persist it.
$XFS_IO_PROG -f -c "pwrite -S 0xaa 0 128K" $SCRATCH_MNT/foo | _filter_xfs_io
sync
workout()
{
local need_sync=$1
# Append some data to the file, increasing its size, and leave a hole between
# the old size and the start offset if the following write. So our file gets
# a hole in the range [128Kb, 256Kb[.
$XFS_IO_PROG -c "pwrite -S 0xbb 256K 32K" $SCRATCH_MNT/foo | _filter_xfs_io
# Create our test file with some data and durably persist it.
$XFS_IO_PROG -t -f -c "pwrite -S 0xaa 0 128K" $SCRATCH_MNT/foo | _filter_xfs_io
sync
# Now truncate our file to a smaller size that is in the middle of the hole we
# previously created. On most truncate implementations the data we appended
# before gets discarded from memory (with truncate_setsize()) and never ends
# up being written to disk.
$XFS_IO_PROG -c "truncate 160K" $SCRATCH_MNT/foo
# Append some data to the file, increasing its size, and leave a hole between
# the old size and the start offset if the following write. So our file gets
# a hole in the range [128Kb, 256Kb[.
$XFS_IO_PROG -c "pwrite -S 0xbb 256K 32K" $SCRATCH_MNT/foo | _filter_xfs_io
_scratch_cycle_mount
# This 'sync' is to flush file extent on disk and update on-disk inode size.
# This is required to trigger a bug in btrfs truncate where it updates on-disk
# inode size incorrectly.
if [ $need_sync -eq 1 ]; then
sync
fi
# We expect to see a file with a size of 160Kb, with the first 128Kb of data all
# having the value 0xaa and the remaining 32Kb of data all having the value 0x00
echo "File content after remount:"
od -t x1 $SCRATCH_MNT/foo
# Now truncate our file to a smaller size that is in the middle of the hole we
# previously created.
# If we don't flush dirty page cache above, on most truncate
# implementations the data we appended before gets discarded from
# memory (with truncate_setsize()) and never ends up being written to
# disk.
$XFS_IO_PROG -c "truncate 160K" $SCRATCH_MNT/foo
_scratch_cycle_mount
# We expect to see a file with a size of 160Kb, with the first 128Kb of data all
# having the value 0xaa and the remaining 32Kb of data all having the value 0x00
echo "File content after remount:"
od -t x1 $SCRATCH_MNT/foo
}
workout 0
# flush after each write
workout 1
status=0
exit
+10
View File
@@ -9,3 +9,13 @@ File content after remount:
0400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0500000
wrote 131072/131072 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 32768/32768 bytes at offset 262144
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
File content after remount:
0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0500000