Perforce Server Disk Cleanup and Repository Size Management: A Safe, Practical Playbook

Originally published on 2014-09-22; fully revised and updated.

If your Perforce (Helix Core) server is low on disk, cleanup should be done in a controlled order so you recover capacity without damaging metadata. This guide expands the original draft checklist into an operator-friendly workflow: establish a baseline, choose the right cleanup method, and validate after each change.

Original post

Where Perforce disk usage usually grows

The original article identified five useful areas. In practice, they map to two categories: measurement (understanding where space is going) and intervention (reclaiming or relocating storage).

• Checkpoint and journal history accumulation over time
• Insufficient capacity under the current P4ROOT filesystem
• Large or stale workspace metadata (including db.have)
• Lack of regular visibility into depot and server storage trends

Disk-space triage workflow

Use a measure-first sequence before deleting anything. This reduces the chance of reclaiming the wrong data or introducing avoidable downtime.

flowchart TD
    A[Capture baseline] --> B[Run p4 diskspace]
    B --> C[Run p4 sizes by depot path]
    C --> D{Main pressure source}
    D --> E[Checkpoint and journal retention cleanup]
    D --> F[Move P4ROOT to larger storage]
    D --> G[Workspace metadata review]
    E --> H[Maintenance window execution]
    F --> H
    G --> H
    H --> I[Post-change validation and monitoring]

Commands to measure space before cleanup

Check server-level disk visibility

p4 diskspace

Use this as a quick operational check to understand available space from the server side before making any cleanup decision.

Estimate depot footprint by path

p4 sizes //depot/...
p4 sizes //depot/projectA/...Code language: JavaScript (javascript)

Run this at broad and narrow scopes to find which depot areas are contributing most to growth.

Cleanup options compared

Operational playbook

1) Clean up old checkpoints and journals first

Create a fresh checkpoint, inventory existing files, and review age before deleting anything. Keep enough history for your recovery policy.

p4 admin checkpoint
ls -lh /p4/1/checkpoints
find /p4/1/checkpoints -type f -mtime +30 -printCode language: PHP (php)

The last command is intentionally non-destructive (preview only). Review output and apply your approved retention policy before removal.

2) Relocate P4ROOT only during a planned maintenance window

If disk pressure is structural, move server root data to a larger volume, then link back. Validate startup and command behavior immediately after.

sudo systemctl stop perforce
sudo rsync -a /p4/1/root/ /data/perforce/root/
sudo mv /p4/1/root /p4/1/root.backup
sudo ln -s /data/perforce/root /p4/1/root
sudo systemctl start perforceCode language: JavaScript (javascript)

p4 info
p4 diskspace
p4 -c workspace_name sync -n //depot/...Code language: JavaScript (javascript)

Service names and paths differ by installation. Treat the above as a template, not a copy-paste runbook.

3) Treat db.have operations as high risk

The original draft mentions deleting db.have. This can affect client sync state and should only be done with version-specific guidance, tested recovery steps, and a rollback plan.

p4 clients
p4 client -d workspace_name

When possible, prefer lower-risk cleanup (for example, removing stale workspaces) before considering direct metadata-table intervention.

Best practices

• Measure first with p4 diskspace and p4 sizes, then decide.
• Use explicit retention rules for checkpoints and journals.
• Run disruptive changes only in maintenance windows with rollback steps.
• Avoid direct metadata-table manipulation unless fully documented and tested for your server version.
• Schedule recurring capacity checks so growth is handled before it becomes an incident.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.