AUFS Performance and Best Practices

very large and only a small part of it is being modified. This can have a noticeable impact on container write performance. AUFS can suffer noticeable latencies when searching for files in images with many layers. However, it is worth noting that the copy_up operation only occurs the first time a given file is written to. Subsequent writes to the same file operate against the copy of the file already copied up to the container. - **Deleting files and directories**: - When a _file_ is deleted within a container, a *whiteout* file is created in the container layer. The version of the file in the image layer is not deleted (because the image layers are read-only). However, the whiteout file prevents it from being available to the container. - When a _directory_ is deleted within a container, an _opaque file_ is created in the container layer. This works in the same way as a whiteout file and effectively prevents the directory from being accessed, even though it still exists in the image layer. - **Renaming directories**: Calling `rename(2)` for a directory is not fully supported on AUFS. It returns `EXDEV` ("cross-device link not permitted"), even when both of the source and the destination path are on a same AUFS layer, unless the directory has no children. Your application needs to be designed to handle `EXDEV` and fall back to a "copy and unlink" strategy. ## AUFS and Docker performance To summarize some of the performance related aspects already mentioned: - The AUFS storage driver is less performant than the `overlay2` driver, but is a good choice for PaaS and other similar use-cases where container density is important. This is because AUFS efficiently shares images between multiple running containers, enabling fast container start times and minimal use of disk space. - The underlying mechanics of how AUFS shares files between image layers and containers uses the page cache very efficiently. - The AUFS storage driver can introduce significant latencies into container write performance. This is because the first time a container writes to any file, the file needs to be located and copied into the containers top writable layer. These latencies increase and are compounded when these files exist below many image layers and the files themselves are large. ### Performance best practices The following generic performance best practices also apply to AUFS. - **Solid State Devices (SSD)** provide faster reads and writes than spinning disks. - **Use volumes for write-heavy workloads**: Volumes provide the best and most predictable performance for write-heavy workloads. This is because they bypass the storage driver and do not incur any of the potential overheads introduced by thin provisioning and copy-on-write. Volumes have other benefits, such as allowing you to share data among containers and persisting even when no running container is using them. ## Related information - [Volumes](../volumes.md) - [Understand images, containers, and storage drivers](index.md) - [Select a storage driver](select-storage-driver.md)

Renaming directories using `rename(2)` on AUFS has limitations, potentially returning `EXDEV` unless the directory is empty, requiring a "copy and unlink" workaround. AUFS is less performant than `overlay2`, but better for container density, sharing images efficiently and using page cache. AUFS introduces latencies in container writes due to 'copy_up' operations, especially with many image layers or large files. SSDs improve performance. Volumes are best for write-heavy workloads, bypassing the storage driver and providing better, more predictable performance.