{"id":375,"date":"2026-10-14T00:31:08","date_gmt":"2026-10-14T00:31:08","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2014\/09\/22\/ways-to-perforce-server-disk-space-cleanup-and-repos-size-management\/"},"modified":"2026-10-14T00:31:08","modified_gmt":"2026-10-14T00:31:08","slug":"ways-to-perforce-server-disk-space-cleanup-and-repos-size-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/ways-to-perforce-server-disk-space-cleanup-and-repos-size-management\/","title":{"rendered":"Perforce Server Disk Cleanup and Repository Size Management: A Safe, Practical Playbook"},"content":{"rendered":"\n

Originally published on 2014-09-22; fully revised and updated.<\/em><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Original post<\/a><\/p>\n\n\n\n

\"perforce-server-disk-space-cleanup-and-repos-size-management\"<\/p>\n\n\n\n

Where Perforce disk usage usually grows<\/h2>\n\n\n\n

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

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

    Disk-space triage workflow<\/h2>\n\n\n\n

    Use a measure-first sequence before deleting anything. This reduces the chance of reclaiming the wrong data or introducing avoidable downtime.<\/p>\n\n\n\n

    \nflowchart TD\n    A[Capture baseline] --> B[Run p4 diskspace]\n    B --> C[Run p4 sizes by depot path]\n    C --> D{Main pressure source}\n    D --> E[Checkpoint and journal retention cleanup]\n    D --> F[Move P4ROOT to larger storage]\n    D --> G[Workspace metadata review]\n    E --> H[Maintenance window execution]\n    F --> H\n    G --> H\n    H --> I[Post-change validation and monitoring]\n<\/pre>\n\n\n\n
    Commands to measure space before cleanup<\/h2>\n\n\n\n
    Check server-level disk visibility<\/h3>\n\n\n
    p4 diskspace<\/code><\/span><\/pre>\n\n\n
    Use this as a quick operational check to understand available space from the server side before making any cleanup decision.<\/p>\n\n\n\n
    Estimate depot footprint by path<\/h3>\n\n\n
    p4 sizes \/\/depot\/...<\/span>\np4 sizes \/\/depot\/projectA\/...<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    Run this at broad and narrow scopes to find which depot areas are contributing most to growth.<\/p>\n\n\n\n
    Cleanup options compared<\/h2>\n\n\n\n
    Option<\/th>What it helps with<\/th>Risk level<\/th>When to use it<\/th><\/tr><\/thead>
    Prune old checkpoints and journals<\/td>Recovers space from backup artifacts<\/td>Medium<\/td>When retention is undefined or too long<\/td><\/tr>
    Move P4ROOT<\/code> to larger storage (symlink or mount strategy)<\/td>Removes immediate filesystem pressure<\/td>Medium to High<\/td>When server metadata volume is outgrowing current disk<\/td><\/tr>
    db.have<\/code> maintenance<\/td>Can reduce workspace metadata burden<\/td>High<\/td>Only with a tested runbook and change control<\/td><\/tr>
    Regular p4 diskspace<\/code> and p4 sizes<\/code> checks<\/td>Prevents surprise capacity incidents<\/td>Low<\/td>As part of normal operations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Operational playbook<\/h2>\n\n\n\n
    1) Clean up old checkpoints and journals first<\/h3>\n\n\n\n
    Create a fresh checkpoint, inventory existing files, and review age before deleting anything. Keep enough history for your recovery policy.<\/p>\n\n\n
    p4 admin checkpoint\nls -lh \/p4\/1<\/span>\/checkpoints\nfind \/p4\/1<\/span>\/checkpoints -type f -mtime +30<\/span> -print<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
    The last command is intentionally non-destructive (preview only). Review output and apply your approved retention policy before removal.<\/p>\n\n\n\n
    2) Relocate P4ROOT only during a planned maintenance window<\/h3>\n\n\n\n
    If disk pressure is structural, move server root data to a larger volume, then link back. Validate startup and command behavior immediately after.<\/p>\n\n\n
    sudo systemctl stop perforce\nsudo rsync -a \/p4\/1<\/span>\/root\/ \/data\/<\/span>perforce\/root\/\nsudo mv \/p4\/1<\/span>\/root \/p4\/1<\/span>\/root.backup\nsudo ln -s \/data\/perforce\/root \/p4\/1<\/span>\/root\nsudo systemctl start perforce<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
    p4 info\np4 diskspace\np4 -c workspace_name sync -n \/\/depot\/...<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    Service names and paths differ by installation. Treat the above as a template, not a copy-paste runbook.<\/p>\n\n\n\n
    3) Treat db.have operations as high risk<\/h3>\n\n\n\n
    The original draft mentions deleting db.have<\/code>. This can affect client sync state and should only be done with version-specific guidance, tested recovery steps, and a rollback plan.<\/p>\n\n\n
    p4 clients\np4 client -d workspace_name<\/code><\/span><\/pre>\n\n\n
    When possible, prefer lower-risk cleanup (for example, removing stale workspaces) before considering direct metadata-table intervention.<\/p>\n\n\n\n
    Best practices<\/h2>\n\n\n\n
    • Measure first with p4 diskspace<\/code> and p4 sizes<\/code>, then decide.<\/li>
    • Use explicit retention rules for checkpoints and journals.<\/li>
    • Run disruptive changes only in maintenance windows with rollback steps.<\/li>
    • Avoid direct metadata-table manipulation unless fully documented and tested for your server version.<\/li>
    • Schedule recurring capacity checks so growth is handled before it becomes an incident.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
      Running out of storage on a Perforce (Helix Core) server can quickly become an availability risk. This guide shows a safer cleanup workflow: measure space first, compare options, then execute changes with minimal operational risk.<\/p>\n","protected":false},"author":1,"featured_media":3540,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[370],"tags":[1817,1816,1820,1122,545,1806,244,373,1821,1823,1822,593,1818,1819,399,732,213,1452],"class_list":["post-375","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-perforce","tag-cleanup","tag-disk-space","tag-disk-space-cleanup","tag-guide","tag-how","tag-instruction","tag-management","tag-perforce","tag-perforce-server","tag-perforce-server-guide","tag-perforce-server-tutorial","tag-process","tag-repos","tag-repos-size-management","tag-server","tag-steps","tag-tutorial","tag-ways"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=375"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/375\/revisions"}],"predecessor-version":[{"id":79255,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/375\/revisions\/79255"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3540"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}