Re: Removal of Device and Free Space

["Christian Völker" <cvoelker@knebb.de>]

Hi Roman,


thanks for you ideas. Unfortunately none is valid here. I have for sure 
no snapshots and I have mounted the device with compression enabled:

root@backuppc42:~# btrfs subvolume list /var/lib/backuppc
root@backuppc42:~# mount| grep backup
/dev/mapper/crypt_drbd2 on /var/lib/backuppc type btrfs 
(rw,noatime,compress=zstd:3,space_cache,subvolid=5,subvol=/)

I do not like the idea of going to full file sync for my rsync backups 
as the bandwidth is my concern here. And it does not help either as I 
have compression enabled, right?

Any further ideas?

Greetings
/CV


Am 14.05.2021 um 19:06 schrieb Roman Mamedov:
> On Fri, 14 May 2021 10:54:16 +0200
> Christian Völker <cvoelker@knebb.de> wrote:
> 
>>       What is occupying so much disk space as the data only has 1.7TB
>> which should fit in 1.8TB (two) devices? (no snapshot, nothing special
>> configured on btrfs). Looks like there are ~400GB allocated which are
>> not from data.
> 
> Check if there are really no stray snapshots left over, which keep around old
> versions of some of your data.
> 
> If not, it could be the infamous Btrfs "extent booking" inefficiency, where the
> whole extent (up to 128 MB) is kept around as long as some part of it is still
> referenced.
> 
> Discussed a bit here: https://www.spinics.net/lists/linux-btrfs/msg90352.html
> 
> Since then I found that not only VMs, but for example it's really
> inefficient space-wise to download torrents onto a Btrfs (without nocow).
> 
> Anything where you overwrite small pieces within a large file, will waste
> space.
> 
> In your case, if it's a backup server and you use rsync or the like in an
> incremental mode updating only the changed blocks, switching that to
> whole-file updates (-W for rsync) could alleviate the issue. Another way is to
> force compression on the filesystem, which clamps the extent size limit down
> from 128 MB to 128 KB and mitigates the problem in another way.
>