Am Di., 22. Okt. 2019 um 12:01 Uhr schrieb Qu Wenruo
<quwenruo.btrfs@xxxxxxx <mailto:quwenruo.btrfs@xxxxxxx>>:
On 2019/10/22 下午5:47, Tobias Reinhard wrote:
> Hi,
>
>
> I noticed that if you punch a hole in the middle of a file the
available
> filesystem space seems not to increase.
>
> Kernel is 5.2.11
>
> To reproduce:
>
> ->mkfs.btrfs /dev/loop1 -f
>
> btrfs-progs v4.15.1
> See http://btrfs.wiki.kernel.org for more information.
>
> Detected a SSD, turning off metadata duplication. Mkfs with -m
dup if
> you want to force metadata duplication.
> Label: (null)
> UUID: 415e925a-588a-4b8f-bdc7-c30a4a0f5587
> Node size: 16384
> Sector size: 4096
> Filesystem size: 1.00GiB
> Block group profiles:
> Data: single 8.00MiB
> Metadata: single 8.00MiB
> System: single 4.00MiB
> SSD detected: yes
> Incompat features: extref, skinny-metadata
> Number of devices: 1
> Devices:
> ID SIZE PATH
> 1 1.00GiB /dev/loop1
>
> ->mount /dev/loop1 /srv/btrtest2
>
> ->for i in $(seq 1 20); do dd if=/dev/urandom of=test$i bs=16M
count=4 ;
> sync ; fallocate -p -o 4096 -l 67100672 test$i && sync ; done
>
> this failed from the 16th file on because of no space left
Btrfs doesn't free the space until all space of a data extent get freed.
In your case, your hole punch is [4k, 64M-4K), thus the 64M extent still
has 4K being used.
So the data extent won't be freed until you free the last 4K.
>
> ->df -T .
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/loop1 btrfs 1048576 935856 2272 100% /srv/btrtest2
>
> ->btrfs fi du .
> Total Exclusive Set shared Filename
> 8.00KiB 8.00KiB - ./test1
> 8.00KiB 8.00KiB - ./test2
> 8.00KiB 8.00KiB - ./test3
> 8.00KiB 8.00KiB - ./test4
> 8.00KiB 8.00KiB - ./test5
> 8.00KiB 8.00KiB - ./test6
> 8.00KiB 8.00KiB - ./test7
> 8.00KiB 8.00KiB - ./test8
> 8.00KiB 8.00KiB - ./test9
> 8.00KiB 8.00KiB - ./test10
> 8.00KiB 8.00KiB - ./test11
> 8.00KiB 8.00KiB - ./test12
> 8.00KiB 8.00KiB - ./test13
> 8.00KiB 8.00KiB - ./test14
> 8.00KiB 8.00KiB - ./test15
> 4.00KiB 4.00KiB - ./test16
> 4.00KiB 4.00KiB - ./test17
> 4.00KiB 4.00KiB - ./test18
> 4.00KiB 4.00KiB - ./test19
> 4.00KiB 4.00KiB - ./test20
> 140.00KiB 140.00KiB 0.00B .
>
> When doing this on XFS or EXT4 it works as expected:
>
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/loop1 ext4 999320 2764 927744 1% /srv/btrtest
> /dev/loop2 xfs 1038336 40456 997880 4% /srv/xfstest
>
> How to i reclaim the space on BTRFS? Defrag does not seem to help.
Rewrite the remaining 4K.
Then the new write 4K will be cowed into a new 4K extent, the old large
64M extent gets fully freed and free space.
Thanks,
Qu
(sorry - for previous bad formated post)
Hi,
okay - thanks for the explanation.
How can I find out that rewriting parts of an extent would free up space?
Tobias