generic/015: Issue sync after deleting the fillup file
authorNikolay Borisov <nborisov@suse.com>
Wed, 14 Mar 2018 14:48:37 +0000 (16:48 +0200)
committerEryu Guan <guaneryu@gmail.com>
Fri, 16 Mar 2018 08:30:52 +0000 (16:30 +0800)
commit6898b0f507ace9ef9aa020bed1db690fff7d1b7f
tree7bc5aae227deca2655f4282f38802fc80afb980d
parent1afc31f99dd686ae2b37c940f4915453eb2ff4b9
generic/015: Issue sync after deleting the fillup file

This test fails on btrfs due to the presence of delayed processing
of file deletes if the file is smaller than 32mb. Initially commit
97575acd7495b412435d06229a6d94ed9a814ada tried to fix a similar
failure by bumping the size of the filesystem. However that change
had a knock-on effect in that the scratch filesystem created is
larger than 100mb and thus not created in mixed mode. This in turn
causes the fs to have only 20mb for file data (rest is taken by DUP
metadata). Naturally, this leads to file freeing taking up to
"transaction commit interval" (default 30 s) time to properly account
the freed space.

Not standards define when unlink operations should be accounted so
btrfs is well within its right to be implemented in that way. So
to avoid this edge case just issue a sync before taking the 2nd
free space reading.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
tests/generic/015