---
title: "Proxmox LXC Disk Space Recovery — fstrim and issue_discards"
aliases: [proxmox-fstrim, lvm-issue-discards, proxmox-disk-thin-provisioning, lxc-disk-space]
tags: [proxmox, lxc, lvm, disk, storage, fstrim, trim, thin-provisioning]
sources:
  - "daily/2026-05-03.md"
created: 2026-05-03
updated: 2026-05-03
---

# Proxmox LXC Disk Space Recovery — fstrim and issue_discards

When a Proxmox LXC container's disk appears full (e.g., 99%) but the container hasn't actually used that much data, the cause is usually that deleted blocks haven't been reclaimed by the thin provisioning layer. LVM thin provisioning allocates blocks on write but doesn't automatically free them on delete. Running `fstrim` inside the container and enabling `issue_discards` in LVM config allows TRIM commands to propagate from the filesystem through LVM to the storage backend.

## Key Points

- **LVM thin provisioning doesn't auto-reclaim deleted blocks** — a container that wrote then deleted large files still shows those blocks as used
- **`fstrim`** tells the filesystem to send TRIM/DISCARD commands for freed blocks — reclaims space immediately
- **`issue_discards = 1`** in `/etc/lvm/lvm.conf` enables LVM to pass DISCARD commands to the underlying storage on every LV delete — prevents future bloat
- **Dramatic results:** CT102 went from 99.39% to 35.80% after fstrim + enabling issue_discards
- Only works with thin LVM volumes (local-lvm, ZFS zvols) — not with directory storage

## Details

### Immediate Recovery: fstrim

Run inside the LXC container (or from the Proxmox host with `pct exec`):

```bash
# Inside the container
fstrim -av
# Outputs: /: 45.2 GiB (48,527,572,992 bytes) trimmed

# Or from Proxmox host
pct exec <CTID> -- fstrim -av
```

`-a` = all mounted filesystems, `-v` = verbose (shows space reclaimed).

### Permanent Fix: issue_discards in LVM

On the **Proxmox host** (not inside the container):

```bash
# Edit LVM config
nano /etc/lvm/lvm.conf

# Find and change:
# issue_discards = 0
# to:
issue_discards = 1

# No restart needed — takes effect on next LVM operation
```

With `issue_discards = 1`, LVM sends DISCARD commands to the underlying block device when logical volumes are removed or blocks freed, keeping thin pools lean.

### Checking Thin Pool Usage

```bash
# On Proxmox host — check thin pool usage
lvdisplay pve/data | grep -E "Pool|Used|Allocated"
# or
pvesm status | grep local-lvm

# More detailed
lvs -o lv_name,data_percent,snap_percent pve
```

If `data_percent` is high but the containers don't have that much actual data, trim is needed.

### When fstrim Doesn't Help

fstrim won't help if:
- The container is using directory storage (not LVM thin/ZFS)
- The underlying storage doesn't support DISCARD (some SSDs, spinning disks without TRIM support)
- The container has genuinely large files that haven't been deleted

In those cases, the data is real and must be cleaned manually:

```bash
# Find large files inside the container
pct exec <CTID> -- find / -type f -size +100M 2>/dev/null | sort -k5 -n
# or
pct exec <CTID> -- du -sh /* 2>/dev/null | sort -rh | head -20
```

### Schedule Regular fstrim

Add a cron job to prevent disk bloat accumulating:

```bash
# On Proxmox host — trim all containers weekly
echo "0 3 * * 0 root pct list | awk 'NR>1{print \$1}' | xargs -I{} pct exec {} -- fstrim -a 2>/dev/null" >> /etc/cron.d/pve-fstrim
```

Or use systemd timer — Proxmox ships with `fstrim.timer` that can be enabled.

## Related Concepts

- [[wiki/concepts/proxmox-lxc-autostart]] — LXC container management basics
- [[wiki/concepts/docker-builder-prune-safe]] — another disk space recovery technique (Docker build cache)
- [[wiki/homelab/_index]] — Proxmox infrastructure context

## Sources

- [[daily/2026-05-03.md]] — CT102 at 99.39% disk usage after Docker operations; `fstrim -av` + `issue_discards = 1` in `/etc/lvm/lvm.conf` reduced to 35.80%; fstrim reclaimed ~65% of used space
