On 8.01.2018 10:43, Nikolay Borisov wrote: > This test has been failing for btrfs for quite some time, > at least since 4.7. There are 2 implementation details of btrfs that > it exposes: > > 1. Currently btrfs filesystem under 100mb are created in Mixed block > group mode. Freespace accounting for it is not 100% accurate - I've > observed around 100-200kb discrepancy between a newly created filesystem, > then writing a file and deleting it and checking the free space. This > falls within %3 and not %1 as hardcoded in the test. > > 2. BTRFS won't flush it's delayed allocation on file deletion if less > than 32mb are deleted. On such files we need to perform sync (missing > in the test) or wait until time elapses for transaction commit. > > Since mixed mode is somewhat deprecated and btrfs is not really intended > to be used on really small devices let's just adjust the test to > create a 101mb fs, which doesn't use mixed mode and really test > freespace accounting. > > Signed-off-by: Nikolay Borisov <nborisov@xxxxxxxx> After further experimentation this test is indeed hitting a very pathological edge case. So when we create a btrfs file system in mixed mode with default raid levels the system chunk occupies 0-4mb. As such we can never allocate a chunk which spans this range so the -1mb in btrfs_calc_avail_data_space is not required in this case. Anyway, I believe this to be a really minor nuisance not worth complicating the code to fix, so I'd suggest this test change be merged. > --- > tests/generic/015 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/generic/015 b/tests/generic/015 > index 78f2b13..416c4ae 100755 > --- a/tests/generic/015 > +++ b/tests/generic/015 > @@ -53,7 +53,7 @@ _supported_os Linux > _require_scratch > _require_no_large_scratch_dev > > -_scratch_mkfs_sized `expr 50 \* 1024 \* 1024` >/dev/null 2>&1 \ > +_scratch_mkfs_sized `expr 101 \* 1024 \* 1024` >/dev/null 2>&1 \ > || _fail "mkfs failed" > _scratch_mount || _fail "mount failed" > out=$SCRATCH_MNT/fillup.$$ > -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
