0

Maybe my understanding of what df does is incorrect?

I am wondering what is the problem here

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 seem btrfs filesystem df neither catches the deletion

sudo btrfs fi df /
Data, single: total=432.37GiB, used=427.79GiB
vrms
  • 287
  • 1
  • 7
  • 17

5 Answers5

0

The deleted file is probably kept open by some process. You can use lsof | grep WS19.qcow2 to discover the affected process; killing it will release the consumed space.

Be aware that the most likely candidate is a running virtual machine. After killing it, all its data will be gone forever (as you already deleted its backing file).

shodanshok
  • 47,711
  • 7
  • 111
  • 180
0

/var/lib/libvirt/images/WS19.qcow2 file is probably disk file for VM(virtual machine) running on your Linux system. Please note that if you delete this file, you will loose the VM permanently.

But if you are sure to delete this file, please stop the VM first, delete the file and then you will be able to see the reclaimed space in your df output.

If still not, you can check using below command which will print size of the deleted file.

lsof |grep -B1 -i "WS19.qcow2" | awk '{s+=$9} END {print s }'

nightWolf
  • 108
  • 6
0

You are using Btrfs - do you know whether snapshots are enabled? It's possible although you deleted the file from the current filesystem view, it is being kept in a snapshot.

btrfs subvolume list / should show you all your subvolumes. If snapshots are present, you can check their individual disk space usage. According to here, you first have to do:

btrfs quota enable <your subvolume root>

and then

btrfs qgroup show <your subvolume> will show you detailed information for each individual subvolume.

Or, according to here, you can use btrfs-list for a more user-friendly view.

0

or your data delete is not synched. Just run the command sync and it should be fine.

yield
  • 771
  • 1
  • 9
  • 24
  • neither `sync /var/lib/libvirt/images/` nor `sync /var/lib/libvirt/images/WS19.qcow2` does anything – vrms Jun 07 '22 at 12:10
0

Your command sudo rm <file.qcow2> return error 0? If rm file which open but used then df show incorrect size. lsof |grep <qcow2> and kill pid.