Neither 'df' nor 'btrfs fi df' showing diff after deleting large files

Support
,
1

I am running out of disk space (the symptom being that virsh won’t create a new vm with an error indicating lack of space.

So I am trying to make space but can not see any difference even after removing quite large items.

1. checking usage

$ sudo df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       443G  436G  4,6G  99% /

2. identifying a large file

$ sudo find /var/lib/libvirt -name WS19.qcow2 -exec ls -lh {} \;
-rw------- 1 root kvm 41G  7. Okt 2020  /var/lib/libvirt/images/WS19.qcow2

3. removing that file

$ sudo find /var/lib/libvirt -name WS19.qcow2 -exec rm {} \;

4. checking usage again

$ sudo df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       443G  436G  4,6G  99% /

so, the deletion of 41G did not change the ‘df -h’ output whatsoever. What am I doing wrong? rm should get rid of this without moving it to the Trash first I think (even checked the Trash. The 41G file is not in there).

it seems btrfs filesystem df neither catches the deletion

sudo btrfs fi df /
Data, single: total=432.37GiB, used=427.79GiB
  1. The VM’s to which that disk belongs are not running.
  2. lsof | grep WS19.qcow2 does not show anything.
  3. the file is not in the trash bin (neither my user’s, nor root’s)

not sure what else I can try

2

I guess, the deleted file still exists in your old BTRFS snapshots.

But the command rm does not seriously delete a file unlike shredding a paper, because there is possible to restore the deleted file when using BTRFS snapshots. That is why the deleted file is still there in the disk.

2 Likes
3

This seems to be a popular question. Perhaps one of the solutions below, or the kernel Btrfs FAQ:

1 Like
4

This is one possibility! Another possibility is not to wait for btrfs to cleanup :wink:
Btrfs needs time to clean up. If this is a ssd, it may take a few seconds. If it is a disk, this may take longer. But you have to understand the problem to solve it. Btrfs IS different !

You are out of space !

Please read: “Out of Space” in the wiki. There you will find your solution.

1 Like
5

actually I have copies in 21 snapshots.

found this in order to automate removal from the snapper pros @SuSE (snapper being the one doing those snapshot on my system)

file=$1

while read a
        do snapshot=$(echo ${a%%/$file})
           btrfs property set $snapshot ro false
           rm -f $a
           btrfs property set $snapshot ro true
        done < <(find /.snapshots/ -name $file)

I guess need to either find a way to exclude /var/lib/libvirt/images from being snapshotted by snapper on each pacman operation

6

This is an easy one :wink:

Create an additional subvolume for your VMs and mount it to /var/lib/libvirt/images

i do have :
@nosnap next to @ and @home

PARTUUID=3ee1dfe1-19bf-4102-945d-90d957d3c199	/var/nosnap		btrfs	rw,noatime,compress=zstd:9,commit=300,subvol=@nosnap		0 0
/var/nosnap/var/cache				/var/cache		none	bind	0 0
/var/nosnap/var/spool				/var/spool		none	bind	0 0

insgesamt 77700077
drwxr-x--- 1 andreas users         922 22. Mai 12:46 iso
drwxr-xr-x 1 root    root           20 31. Mai 2019  var
drwxrwx--- 1 andreas users         100 22. Mai 12:47 VMs

No snapshots of

  • iso
  • vms
  • /var/cache
  • /var/spool
7

/home/$USER/.local/share/Steam too, it is pretty big

1 Like
8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

9

I seem not to have right to re-open my previous topic so I am Continuing the discussion from Neither 'df' nor 'btrfs fi df' showing diff after deleting large files:

hm … despite the fact I have manually removed all copies of that file in all snapshots now I am not making any progress

$ sudo btrfs fi df /
Data, single: total=432.37GiB, used=432.37GiB

neither does $ sudo find / -name WS19.qcow2 return any remaining copy.

10

repeating the exercise with another large file seems to work though

12

When a thread is marked as solved, it will go to readonly after 3 days :wink:

This will only work,

  • if you have mountet all your snapshots, or
  • if you have mounted btrfs-root like:
mount -o subvol=/ /dev/sdxxx /mnt

Deleting files in snapshots is only possible if the snapshots are rw
But standard for creating snapshots is readonly