It shows that the disk folder occupies 450G. It is quite a big difference between 32G and 450G. Is it some sort of cache? Is there a way to clean it up too?
OK so the issue here is that your LVM storage pool is using a loopback image file /var/snap/lxd/common/lxd/disks/default.img which has a fixed maximum size of 800GB. Then the LVM volume group is created ontop of that. The disk image file is created as a sparse file, which means it won’t use the full 800GB straight away and instead it will consume space as the LVM subsystem uses it.
However I don’t think the LVM subsystem will release the space on the virtual disk once it has been used, even if the volumes are deleted. It will still keep the space (as normally the disk or partition size would be fixed if it was a real disk).
I would suggest you create a new smaller LVM pool and then copy the instances to it, then remove the old one.
Yes so the sparse file is 800GB in size, so thats the maximum it will grow to. When you use du it is showing the size of the allocated blocks in that image file (circa 450GB), but not all of that is “used”, its just not available to other files on the system.
Then when you create LVM volumes, they may use some of that already allocated space or they may use more space (up to the maximum size of the disk image) - this depends on how LVM allocates the blocks.
When you delete or resize and LVM volume the blocks are reused so the lxc storage info command is just showing how much of the volume group is actively assigned to volumes.
Its worth also noting that this same thing occurs at the lower level inside the LVM volumes themselves. You may have a volume of, say, 10GB, and the filesystem inside the container shows less usage than the LVM subsystem (via lvs) sees because the blocks have been used by the filesystem by not released when a file is deleted/reduced in size (its still available for reuse though).