14 days ago
Service: turso (ghcr.io/tursodatabase/libsql-server:latest) with a 5000 MB volume mounted at /var/lib/libsql.
Symptom: The service's DISK_USAGE_GB metric reads ~0.46-0.74 GB in both my production and development environments, but the volume genuinely holds ~0.2-2.7 MB - about a 1000x gap. The dashboard therefore shows ~1 GB "disk usage" for a DB that's essentially empty.
How I verified (SSH'd into the service, ground truth, no changes made):
- df -h /var/lib/libsql -> 2.7 MB used / 4.5 GB avail (1%) in prod; 216 KB in dev
- du -ah /var/lib/libsql -> ~1.5 MB total, including the SQLite WAL (data-wal ~636 KB, wallog ~664 KB)
- The figure is flat and stable across re-polls, so it's not lagging behind a checkpoint or VACUUM
- No deleted-but-open files; nothing held open; the volume is genuinely empty
Question: Is this a known metric-accounting bug for libsql-server with a mounted volume (WAL counting / stale sector accounting)? It reproduces identically in two independent environments on the same image, and since the volume is verifiably nearly empty, it looks like a display/billing reporting artifact rather than real data usage.
Has anyone else run libsql/turso here and seen disk usage report far above the real volume? Any workaround, or is this best reported as a bug? Thanks!
1 Replies
14 days ago
The gap between the dashboard's DISK_USAGE metric and what df/du shows inside the container is expected and not a bug. The metric reports the ZFS zvol's allocated blocks on the host, not the logical size of live files. Volumes allocate storage in 16 KB blocks while ext4 frees space in 4 KB blocks, so partially freed blocks can never be returned, and workloads with frequent small-file rewrites (like SQLite WAL cycling) settle at a permanently higher allocation floor. Your production volume reads ~739 MB allocated and development ~457 MB at the host layer, which is exactly the 0.46-0.74 GB you see. Billing is based on this same metric (at $0.15/GB-month), so the real cost of the gap is roughly $0.07-$0.11/month per environment. There is no reclaim operation or workaround that brings the figure down to the df value, and fstrim inside the container will fail with "Operation not permitted" (expected). Nothing is wrong with your data or your volume.
Status changed to Awaiting User Response Railway • 14 days ago
Status changed to Solved herdibintang • 14 days ago