Re: Effect of punching holes

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

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



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

> 
> Best regards
> 
> 
> Tobias
> 


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