This test case takes a long time to complete at the default
LOAD_FACTOR=1, so reduce the nr_extents to 256, so for larger
systems it can still use higher LOAD_FACTOR.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs-progs patch[1] replaced read(2) write(2) with splice(2) and
caused the append-redirect to stop working.
Before:
btrfs send /btrfs/ro_send > /dev/null
At subvol /btrfs/ro_snap
btrfs send /btrfs/ro_send >> /dev/null
At subvol /btrfs/ro_snap
After:
btrfs send /btrfs/ro_send > /dev/null
At subvol /btrfs/ro_snap
btrfs send /btrfs/ro_send >> /dev/null
At subvol /btrfs/ro_snap
ERROR: failed to read stream from kernel: Invalid argument
Further in the test case the line..
btrfs/130
::
_run_btrfs_util_prog send $SCRATCH_MNT/ro_snap > /dev/null 2>&1
which intended to redirect send output to /dev/null, but ended up
append redirect to the $seqres.full file. And so this test case
failed as 'Invalid argument' for sometime now.
Still as append of a btrfs send output doesn't make sense, so fix
the fstests.
Also adds logs going into $seqres.full.
[1]
ba23855cdc8961bbaef1fcad4854d494cdb3afd3
btrfs-progs: send: use splice syscall instead of read/write to transfer buffer
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For fully deduped file, whose file extents are all pointing to the
same extent, btrfs backref walk can be very time consuming, long
enough to trigger softlock.
Unfortunately, btrfs send is one of the caller of such backref walk
under an O(n) loop, making the total time complexity to O(n^3) or
more.
And even worse, btrfs send will allocate memory in such loop, to
trigger OOM on system with small memory(<4G).
This test case will check if btrfs send will cause these problems.
Reporeted-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>