Re: Effect of punching holes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux