Disk space allocation

Disk space usage by Helix Core Server depends on these factors:

Factor Description

Factor	Description
Number and size of client workspaces Directories on your machine where you work on file revisions that are managed by Helix Core Server. By default, this name is set to the name of the machine on which your client workspace is located, but it can be overridden. Client workspaces, labels, and branch specifications cannot share the same name.	The size of the files that your users need in their client workspaces at any one time.
Size of server database of metadata The data stored by Helix Core Server that describes the file revisions in the depot, where they get their content from (see lazy copy), and the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the archive files that users submit.	Approximately 0.5 kilobytes per user per file. For example, a system with 10,000 files and 50 users initially requires 250 MB of disk space for the database. However, the database grows larger over time because the histories of the individual files grows over time. The `db.have` file holds the list of files opened in client workspaces. This file tends to grow more rapidly than other files in the database. If you are experiencing issues related to the size of your `db.have` file and are unable to quickly switch to a server with adequate support for large files, consider deleting unused client workspace specifications and reducing the scope of client workspace views.
Size of server’s archive of versioned files Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'.	The size of the server’s archive of versioned files depends on the sizes of the original files stored and grows as revisions are added. Allocate sufficient space in your `P4ROOT` directory to hold at least three times the size of your users' present collection of versioned files, plus an additional 0.5KB per user per file to hold the database files that store the list of depot files, file status, and file revision histories.

Directories on your machine where you work on file revisions that are managed by Helix Core Server. By default, this name is set to the name of the machine on which your client workspace is located, but it can be overridden. Client workspaces, labels, and branch specifications cannot share the same name.

The size of the files that your users need in their client workspaces at any one time.

Size of server database of metadata

The data stored by Helix Core Server that describes the file revisions in the depot, where they get their content from (see lazy copy), and the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the archive files that users submit.

Approximately 0.5 kilobytes per user per file. For example, a system with 10,000 files and 50 users initially requires 250 MB of disk space for the database. However, the database grows larger over time because the histories of the individual files grows over time.

The db.have file holds the list of files opened in client workspaces. This file tends to grow more rapidly than other files in the database.

If you are experiencing issues related to the size of your db.have file and are unable to quickly switch to a server with adequate support for large files, consider deleting unused client workspace specifications and reducing the scope of client workspace views.

Size of server’s archive of versioned files Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'.

The size of the server’s archive of versioned files depends on the sizes of the original files stored and grows as revisions are added. Allocate sufficient space in your P4ROOT directory to hold at least three times the size of your users' present collection of versioned files, plus an additional 0.5KB per user per file to hold the database files that store the list of depot files, file status, and file revision histories.