Re: Have 15GB missing in btrfs filesystem.

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

 




On 2018/10/24 上午8:36, Marc MERLIN wrote:
> Normally when btrfs fi show will show lost space because 
> your trees aren't balanced.

Not always the case.

Btrfs uses two level allocation:
1) Chunk
   2 types, data, metadata, and system.

   And that's "used" space of "btrfs fi show", or "Device allocated" of
   "btrfs fi usage"

2) Extent
   2 types, data and metadata.

   And that's "used" space of "btrfs fi df"

A metadata extent can only get allocated from a metadata chunk
(or a system chunk, but system chunks are pretty small).
A data extent can only get allocated from data chunk.

Balance can only solve the case where an near empty metadata chunk can't
be freed since it's still used by some metadata extents, or similar case
for data chunks.

It can't really magically reclaim free space from void.


From your description, I don't think it's the case.

> Balance usually reclaims that space, or most of it.
> In this case, not so much.
> 
> kernel 4.17.6:
> 
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
> 	Total devices 1 FS bytes used 186.89GiB
> 	devid    1 size 228.67GiB used 207.60GiB path /dev/mapper/pool1
> 
> Ok, I have 21GB between used by FS and used in block layer.
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=40 -v .
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=40
> Done, had to relocate 1 out of 210 chunks
> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=60 -v .
> Dumping filters: flags 0x6, state 0x0, force is off
>   METADATA (flags 0x2): balancing, usage=60
>   SYSTEM (flags 0x2): balancing, usage=60
> Done, had to relocate 4 out of 209 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
> 	Total devices 1 FS bytes used 186.91GiB
> 	devid    1 size 228.67GiB used 205.60GiB path /dev/mapper/pool1
> 
> That didn't help much, delta is now 19GB
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=80 -v .
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=80
> Done, had to relocate 8 out of 207 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
> 	Total devices 1 FS bytes used 187.03GiB
> 	devid    1 size 228.67GiB used 201.54GiB path /dev/mapper/pool1
> 
> Ok, now delta is 14GB
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=80 -v .
> Dumping filters: flags 0x6, state 0x0, force is off
>   METADATA (flags 0x2): balancing, usage=80
>   SYSTEM (flags 0x2): balancing, usage=80
> Done, had to relocate 5 out of 202 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
> 	Total devices 1 FS bytes used 188.24GiB
> 	devid    1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1
> 
> and it's back to 15GB :-/
> 
> How can I get 188.24 and 203.54 to converge further? Where is all that
> space gone?

Your original chunks are already pretty compact.
Thus really no need to do extra balance.

You may get some extra space by doing full system balance (no usage=
filter), but that's really not worthy in my opinion.

Maybe you could try defrag to free some space wasted by CoW instead?
(If you're not using many snapshots)

Thanks,
Qu

> 
> Thanks,
> Marc
> 

Attachment: signature.asc
Description: OpenPGP digital signature


[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