Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Filesystem

File size and disk I/O are the key issues here. For more information, see Filesystems.

## Filesystem performance

P4 Server is judicious with its use of disk I/O. P4 Server metadata is well-keyed, and accesses are mostly sequential scans of limited subsets of the data. The most disk-intensive activity is file check-in, where the P4 Server must write and rename files in the archive. Server performance depends heavily on the operating system’s filesystem implementation, and in particular, on whether directory updates are synchronous. Server performance is also highly dependent upon the capabilities of the underlying hardware’s I/O subsystem.

P4 Server does not recommend any specific hardware configuration or file system. Linux servers tend to have the best performance because of Linux’s asynchronous directory updating. However, a Linux server might have poor recovery if power is cut at the wrong time.

Performance in systems where database and versioned files are stored on NFS-mounted volumes is typically dependent on the implementation of NFS and the underlying storage hardware. P4 Server has been tested and is supported using implementations that support the `flock` protocol.

Under Linux and FreeBSD, database updates over NFS can be an issue because file locking is relatively slow. If the journal is NFS-mounted on these platforms, all operations will be slower. In general (particularly on Linux and FreeBSD), we recommend that the P4 Server database, depot, and journal files be stored on disks that are local to the machine running the P4 Server process or that they be stored on a low-latency SAN device.

These issues affect only the P4 Server process (`p4d`). P4 Server applications, (such as `p4`, the P4 Server Command-Line Client) have always been able to work with client workspaces on NFS-mounted drives (for instance, workspaces in the users' home directories).

## Separate physical drives for server root and journal

The `P4ROOT` directory contains the metadata database and versioned file 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'.s.

We recommend that the `P4ROOT` directory be on a different physical drive than your journal file because:

- If a disk failure corrupts the drive containing `P4ROOT`, your journal file will not be affected. You can then use the journal file to restore any lost or damaged metadata.
- Separating the live journal from the `db.*` files can improve performance.

### Location of server root and the journal

You can set the location for the metadata database and the journal file when you install the server. You can also change the location later by moving files and reconfiguring the server. See the environment variables P4ROOT and P4JOURNAL in the P4 CLI Reference.

### Location of versioned files

You can set the location of the versioned files after installing P4 Server. To set the location for:

- all depots, use the server.depot.root configurable

- for individual depots, use the `Map:` form field in the p4 depot spec to specify an absolute location

See also Backup and recovery and in Location of db.* files, journal, and depot files.

Your search for returned results