A large ZimaOS swap file is not the same thing as active swap pressure, and deleting it is not the right way to recover boot-disk space. Check actual swap usage, memory pressure, Docker disk usage, logs, and AppData location before changing swap configuration.
The 2026 source thread blamed a 3.8GB .swap file for a nearly full 48GB boot disk, but the math showed swap was only a small part of the missing space. The system later recovered about 20GB, which points toward temporary Docker/cache cleanup rather than swap shrinking.
Reserved Swap Size vs Active Swap Usage
Run:
free -h
swapon --showA 4GB swap file can exist on disk while only a tiny fraction is in use. The file's size is reserved capacity; it does not mean RAM has overflowed by 4GB.
Find What Is Filling the System Disk
Run:
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hDocker image layers, writable overlays, logs, caches, and temporary data can occupy the small system disk even when application media is mapped elsewhere.
Keep AppData Off the System Drive
The current ZimaOS app data guide explicitly recommends setting App data location to a storage space instead of filling the system drive.
This does not eliminate all Docker-system usage, but it prevents application databases and media caches from consuming the boot device by default.
Check Container Logs
A noisy container can grow JSON logs rapidly. Inspect Docker disk usage and container log sizes before deleting random files.
If one app is responsible, fix its logging behavior or rotate logs rather than manually deleting active log files.
High Swap Usage Can Still Mean RAM Pressure
If free -h shows little available memory and swap is actively used, identify the processes consuming RAM. Heavy databases, photo indexing, AI workloads, and VMs can push a small-memory system into swap.
Do Not Disable Swap Just to Hide the Symptom
Swap can keep the system alive during short memory spikes. Disabling it on a memory-constrained server can convert slowdown into out-of-memory kills.
When to Add RAM
Add RAM when sustained workloads consistently exhaust physical memory and important services are paging heavily. Do not upgrade RAM solely because a swap file exists.
The performance troubleshooting guide helps avoid treating every slow server as a RAM issue.
Measure Memory Pressure Over Time
A single free -h snapshot can be misleading because Linux deliberately uses spare RAM for cache. Look at available memory and whether swap-in/swap-out activity continues during the workload.
If tools available on the system show sustained swapping while the server feels slow, identify which app or VM is consuming memory rather than focusing only on the size of the swap file.
Docker Images Still Consume System Space
Moving AppData to /DATA does not move every Docker image layer and runtime file. Installing and updating many apps can therefore grow the system disk even when all user-facing data volumes point elsewhere.
Before pruning, use Docker's own disk-usage view to distinguish images, containers, local volumes, and build cache. Remove only objects you know are unused.
Check Whether a Small System Disk Is the Structural Problem
A 48GB boot disk can work, but it leaves little margin for multiple app images, updates, logs, and temporary operations. If the system repeatedly approaches 100% despite healthy cleanup, a larger system disk or moving more persistent workloads to main storage may be the sustainable fix.
Low Free Space Can Cause Secondary Failures
When the writable system area is nearly full, app updates, database writes, logs, and temporary files can fail in ways that look unrelated to storage. Treat very low free space as an operational risk even if the server has terabytes free on another array.
FAQ
Why did free disk space come back overnight?
Temporary Docker layers, caches, logs, or cleanup jobs may have released space. That does not mean the swap file itself shrank.
Should I delete the .swap file?
No. Check active swap usage and the real disk-space consumers first.
Is 3โ4GB swap normal?
The existence of a few-gigabyte swap file is not unusual. What matters is how much swap is actively used and whether memory pressure is sustained.
Why is my boot disk still used when AppData is on /DATA?
Docker engine metadata, image layers, runtime overlays, logs, and system files still live outside your mapped application data.
