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)
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

index bdae86dd6fb204bff79d6a977d8e409a9db90be9..cb7252b98e46f5a38483a2f96d94f385237f500c 100755 (executable)
@@ -115,6 +115,8 @@ fi
 
 echo "check free space:"
 
+sync
+
 free2=`_free`
 if [ -z "$free2" ]
 then