Re: Effect of punching holes

[Tobias Reinhard <trtracer@gmail.com>]

Am Di., 22. Okt. 2019 um 12:01 Uhr schrieb Qu Wenruo 
<quwenruo.btrfs@gmx.com <mailto:quwenruo.btrfs@gmx.com>>:



    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