Helix Core Server Administrator Guide: Fundamentals (2019.1)

Filesystem

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

Filesystem performance

Helix server is judicious with its use of disk I/O. Helix 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 Helix Core 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.

Helix 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. Helix 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 Helix server database, depot, and journal files be stored on disks that are local to the machine running the Helix Core server process or that they be stored on a low-latency SAN device.

These issues affect only the Helix Core server process (p4d). Helix server applications, (such as p4, the Helix 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

We recommend that the P4ROOT directory (that is, the directory containing your database and versioned files) be on a different physical drive than your journal file:

  • By storing the journal on a separate drive, you can be reasonably certain that, if a disk failure corrupts the drive containing P4ROOT, such a failure will not affect your journal file. You can then use the journal file to restore any lost or damaged metadata.
  • Separating the live journal from the db.* files can also improve performance.

See Backup and recovery and in Journal and archive location.