Re: [PATCH] btrfs: don't end the transaction for delayed refs in throttle

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2227 bytes --]



On 2019/2/13 上午12:03, David Sterba wrote:
> On Thu, Jan 24, 2019 at 09:31:43AM -0500, Josef Bacik wrote:
>> Previously callers to btrfs_end_transaction_throttle() would commit the
>> transaction if there wasn't enough delayed refs space.  This happens in
>> relocation, and if the fs is relatively empty we'll run out of delayed
>> refs space basically immediately, so we'll just be stuck in this loop of
>> committing the transaction over and over again.
>>
>> This code existed because we didn't have a good feedback mechanism for
>> running delayed refs, but with the delayed refs rsv we do now.  Delete
>> this throttling code and let the btrfs_start_transaction() in relocation
>> deal with putting pressure on the delayed refs infrastructure.  With
>> this patch we no longer take 5 minutes to balance a metadata only fs.
>>
>> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> 
> For the record, this has been merged to 5.0-rc5
> 

Bisecting leads me to this patch for strange balance ENOSPC.

Can be reproduced by btrfs/156, or the following small script:
------
#!/bin/bash
dev="/dev/test/test"
mnt="/mnt/btrfs"

_fail()
{
	echo "!!! FAILED: $@ !!!"
	exit 1
}

do_work()
{
	umount $dev &> /dev/null
	umount $mnt &> /dev/null

	mkfs.btrfs -b 1G -m single -d single $dev -f > /dev/null

	mount $dev $mnt

	for i in $(seq -w 0 511); do
	#	xfs_io -f -c "falloc 0 1m" $mnt/file_$i > /dev/null
		xfs_io -f -c "pwrite 0 1m" $mnt/inline_$i > /dev/null
	done
	sync

	btrfs balance start --full $mnt || return 1
	sync


	btrfs balance start --full $mnt || return 1
	umount $mnt
}

failed=0
for i in $(seq -w 0 24); do
	echo "=== run $i ==="
	do_work
	if [ $? -eq 1 ]; then
		failed=$(($failed + 1))
	fi
done
if [ $failed -ne 0 ]; then
	echo "!!! failed $failed/25 !!!"
else
	echo "=== all passes ==="
fi
------

For v4.20, it will fail at the rate around 0/25 ~ 2/25 (very rare).
But at that patch (upstream commit
302167c50b32e7fccc98994a91d40ddbbab04e52), the failure rate raise to 25/25.

Any idea for that ENOSPC problem?
As it looks really wired for the 2nd full balance to fail even we have
enough unallocated space.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]