mirror of
https://github.com/linux-apfs/apfstests.git
synced 2026-05-01 15:01:44 -07:00
Filipe Manana
f6879e8a78
A bug in file cloning/reflinking was recently found that afftected both
Btrfs and XFS, which was caused by allowing the cloning of an eof block
into the middle of a file when the eof is not aligned to the filesystem's
block size.
The fix consists of returning the errno -EINVAL to user space when the
arguments passed to the system call lead to the scenario of data
corruption. However this overlaps with some cases where the system call,
in Btrfs, returned -EOPNOTSUPP, which means we are trying to reflink
inline extents. That is unsupported in Btrfs due to the huge complexity
of supporting it (due to copying and trimming inline extents, deal with
eventual compression, etc).
We have a few btrfs test cases that verify that attempts to clone inline
extents result in a failure, and are currently expecting an -EINVAL error
message from the output of the cloner program. So create a filter that
converts error messages related to the -EOPNOTSUPP error to messages
related to the -EINVAL error, so that the test can run both on patched
and non-patched linux kernels.
The corresponding btrfs patch for the linux kernel is titled:
"Btrfs: fix data corruption due to cloning of eof block"
And the VFS change that introduces the -EINVAL error return was introduced
by the following linux kernel commit (landed in 4.20-rc1):
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
The btrfs patch is not yet in Linus' tree (it was submitted around the
same time as this change) and the VFS change was introduced in 4.10-rc1.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
120 lines
5.1 KiB
Bash
Executable File
120 lines
5.1 KiB
Bash
Executable File
#! /bin/bash
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
# Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
|
|
#
|
|
# FSQA Test No. 113
|
|
#
|
|
# Test that truncating a file that consists of a compressed and inlined extent
|
|
# to a smaller size and then cloning it into another file is not possible and
|
|
# does not result in leaking stale data (data past the truncation offset) nor
|
|
# losing data in the clone operation's destination file.
|
|
#
|
|
seq=`basename $0`
|
|
seqres=$RESULT_DIR/$seq
|
|
echo "QA output created by $seq"
|
|
tmp=/tmp/$$
|
|
status=1 # failure is the default!
|
|
trap "_cleanup; exit \$status" 0 1 2 3 15
|
|
|
|
_cleanup()
|
|
{
|
|
cd /
|
|
rm -f $tmp.*
|
|
}
|
|
|
|
# get standard environment, filters and checks
|
|
. ./common/rc
|
|
. ./common/filter
|
|
. ./common/filter.btrfs
|
|
|
|
# real QA test starts here
|
|
_supported_fs btrfs
|
|
_supported_os Linux
|
|
_require_scratch
|
|
_require_cloner
|
|
|
|
rm -f $seqres.full
|
|
|
|
_scratch_mkfs >>$seqres.full 2>&1
|
|
_scratch_mount "-o compress"
|
|
|
|
# Create our test files. File foo is going to be the source of a clone operation
|
|
# and consists of a single inline extent with an uncompressed size of 512 bytes,
|
|
# while file bar consists of a single inline extent with an uncompressed size of
|
|
# 256 bytes. For our test's purpose, it's important that file bar has an inline
|
|
# extent with a size smaller than foo's inline extent.
|
|
$XFS_IO_PROG -f -c "pwrite -S 0xa1 0 128" \
|
|
-c "pwrite -S 0x2a 128 384" \
|
|
$SCRATCH_MNT/foo | _filter_xfs_io
|
|
$XFS_IO_PROG -f -c "pwrite -S 0xbb 0 256" $SCRATCH_MNT/bar | _filter_xfs_io
|
|
|
|
# Now durably persist all metadata and data. We do this to make sure that we get
|
|
# on disk an inline extent with a size of 512 bytes for file foo.
|
|
sync
|
|
|
|
# Now truncate our file foo to a smaller size. Because it consists of a
|
|
# compressed and inline extent, btrfs did not shrink the inline extent to the
|
|
# new size (if the extent was not compressed, btrfs would shrink it to 128
|
|
# bytes), it only updates the inode's i_size to 128 bytes.
|
|
$XFS_IO_PROG -c "truncate 128" $SCRATCH_MNT/foo
|
|
|
|
# Now clone foo's inline extent into bar.
|
|
# This clone operation should fail with errno EOPNOTSUPP because the source
|
|
# file consists only of an inline extent and the file's size is smaller than
|
|
# the inline extent of the destination (128 bytes < 256 bytes). However the
|
|
# clone ioctl was not prepared to deal with a file that has a size smaller
|
|
# than the size of its inline extent (something that happens only for compressed
|
|
# inline extents), resulting in copying the full inline extent from the source
|
|
# file into the destination file.
|
|
#
|
|
# Note that btrfs' clone operation for inline extents consists of removing the
|
|
# inline extent from the destination inode and copy the inline extent from the
|
|
# source inode into the destination inode, meaning that if the destination
|
|
# inode's inline extent is larger (N bytes) than the source inode's inline
|
|
# extent (M bytes), some bytes (N - M bytes) will be lost from the destination
|
|
# file. Btrfs could copy the source inline extent's data into the destination's
|
|
# inline extent so that we would not lose any data, but that's currently not
|
|
# done due to the complexity that would be needed to deal with such cases
|
|
# (specially when one or both extents are compressed), returning EOPNOTSUPP, as
|
|
# it's normally not a very common case to clone very small files (only case
|
|
# where we get inline extents) and copying inline extents does not save any
|
|
# space (unlike for normal, non-inlined extents).
|
|
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar \
|
|
| _filter_btrfs_cloner_error
|
|
|
|
# Now because the above clone operation used to succeed, and due to foo's inline
|
|
# extent not being shinked by the truncate operation, our file bar got the whole
|
|
# inline extent copied from foo, making us lose the last 128 bytes from bar
|
|
# which got replaced by the bytes in range [128, 256[ from foo before foo was
|
|
# truncated - in other words, data loss from bar and being able to read old and
|
|
# stale data from foo that should not be possible to read anymore through normal
|
|
# filesystem operations. Contrast with the case where we truncate a file from a
|
|
# size N to a smaller size M, truncate it back to size N and then read the range
|
|
# [M, N[, we should always get the value 0x00 for all the bytes in that range.
|
|
|
|
# We expected the clone operation to fail with errno EOPNOTSUPP and therefore
|
|
# not modify our file's bar data/metadata. So its content should be 256 bytes
|
|
# long with all bytes having the value 0xbb.
|
|
#
|
|
# Without the btrfs bug fix, the clone operation succeeded and resulted in
|
|
# leaking truncated data from foo, the bytes that belonged to its range
|
|
# [128, 256[, and losing data from bar in that same range. So reading the
|
|
# file gave us the following content:
|
|
#
|
|
# 0000000 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1
|
|
# *
|
|
# 0000200 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a
|
|
# *
|
|
# 0000400
|
|
echo "File bar's content after the clone operation:"
|
|
od -t x1 $SCRATCH_MNT/bar
|
|
|
|
# Also because the foo's inline extent was not shrunk by the truncate
|
|
# operation, btrfs' fsck, which is run by the fstests framework everytime a
|
|
# test completes, failed reporting the following error:
|
|
#
|
|
# root 5 inode 257 errors 400, nbytes wrong
|
|
|
|
status=0
|
|
exit
|