Easiest way to trim .raw container? PLEASE help

[ga_lewis]

I have a proxmox container running a Turnkey fileserver that provides a samba window file share to a 1.8TB media drive on Proxmox. The fileshare is accessed by other containers and VMs. The 1.8TB MediaDrive (/dev/sda) is mounted in the fileserver container. The problem is t has no free space even though I'm only actually storing about 300GB on it. I understand from an earlier post that this is because its a .raw file? Some screenshots below.

I'd really appreciate some quick advice /tips on the easiest way to fix this please (so it doesn't happen again)? If at all possible I'd prefer not to to reinstall proxmox and setup the file server and other containers and VMs again.

(p.s In case it is helpful, with respect to the other drives in the second screenshot, /dev/sdb, is a backup drive and actually two 1TB drives mirorred using hardware, and the nvme drive is an SSD on which the proxmox node is installed)

Thank you!!!

 

[LnxBil]

You cannot trim a raw file, if you want to free up space. You can however overwrite the free space with zero, that is also technically a solution to trim space if and only if the underlying storage does have a way to reclaim zero blocks, which ext4 has not (at least after the fact, there exist holes).

Having one raw file on a filesystem on a block storage is also not a good way to do this. Maybe having thin-lvm will be a bit better, yet in the end, I always recommend using ZFS with containers. You just have files on a filesystem instead of a filesystem in a file on a filesystem.

 

[ga_lewis]

You cannot trim a raw file, if you want to free up space. You can however overwrite the free space with zero, that is also technically a solution to trim space if and only if the underlying storage does have a way to reclaim zero blocks, which ext4 has not (at least after the fact, there exist holes).

Having one raw file on a filesystem on a block storage is also not a good way to do this. Maybe having thin-lvm will be a bit better, yet in the end, I always recommend using ZFS with containers. You just have files on a filesystem instead of a filesystem in a file on a filesystem.

Thanks @LnxBil appreciate your advice! I'm still not sure how to actually go about solving this. In terms of practical steps how would I change what I currently have to use ZFS (or thin-lvm if that's much easier)

 

[LnxBil]

In terms of practical steps how would I change what I currently have to use ZFS (or thin-lvm if that's much easier)

You need to move the data "out of the way" to reformat the disk. This can be easily done via backup & restore.

Keep in mind that ZFS should not be run on hardware raid, so you need to break up the hardware raid and setup software raid with ZFS if you plan to use it. LVM-thin will just work out of the box, yet LVM-thin has other problems regarding thin provisioning due to the big allocation units. You may not have full benefity you would get with ZFS (single filesystem solution, compared to block storage with filesystem on top).

The underlying structure is suboptimal for what you want ... having only one container on the disk is bad. Maybe you should consider moving your OS part of the container into another PVE storage and just passthrough the raid volume filesystem (not the disk itself, do a bind mount) to this container and manage the files there as they are. This may be the best your can do with terms of complexity. All the additional virtualization layers for just one container is questionable.

 

[ga_lewis]

You need to move the data "out of the way" to reformat the disk. This can be easily done via backup & restore.

Keep in mind that ZFS should not be run on hardware raid, so you need to break up the hardware raid and setup software raid with ZFS if you plan to use it. LVM-thin will just work out of the box, yet LVM-thin has other problems regarding thin provisioning due to the big allocation units. You may not have full benefity you would get with ZFS (single filesystem solution, compared to block storage with filesystem on top).

The underlying structure is suboptimal for what you want ... having only one container on the disk is bad. Maybe you should consider moving your OS part of the container into another PVE storage and just passthrough the raid volume filesystem (not the disk itself, do a bind mount) to this container and manage the files there as they are. This may be the best your can do with terms of complexity. All the additional virtualization layers for just one container is questionable.

Thanks so much @LnxBil !!!