Docker For Mac Slow Ext4 Partition

I've found that creating a CoreOS VM under Parallels, then using the Docker that is inside CoreOS is far faster than Docker for Mac (currently running Version 17.12.0-ce-mac49 (21995)). I'm doing Linux code builds using CMAKE/Ninja/GCC and it's almost twice as fast as the exact same build from Docker for Mac. Mar 24, 2016 docker info Containers: 2 Images: 3 Server Version: 1.9.1 Storage Driver: devicemapper Pool Name: docker-254:1-4458480-pool Pool Blocksize: 65.54 kB Base Device Size: 10.74 GB Backing Filesystem: Data file: /dev/loop0 Metadata file: /dev/loop1 Data Space Used: 2.52 GB Data Space Total: 107.4 GB Data Space Available: 96.38 GB Metadata Space Used.

1. Docker For Mac Slow Ext4 Partition Recovery Software
2. Mac Slow Internet

Estimated reading time: 11 minutes

I've found that creating a CoreOS VM under Parallels, then using the Docker that is inside CoreOS is far faster than Docker for Mac (currently running Version 17.12.0-ce-mac49 (21995)). I'm doing Linux code builds using CMAKE/Ninja/GCC and it's almost twice as fast as the exact same build from Docker for Mac.

Btrfs is a next generation copy-on-write filesystem that supports many advancedstorage technologies that make it a good fit for Docker. Btrfs is included inthe mainline Linux kernel.

Docker’s btrfs storage driver leverages many Btrfs features for image andcontainer management. Among these features are block-level operations, thinprovisioning, copy-on-write snapshots, and ease of administration. You caneasily combine multiple physical block devices into a single Btrfs filesystem.

This article refers to Docker’s Btrfs storage driver as btrfs and the overallBtrfs Filesystem as Btrfs.

Note: The btrfs storage driver is only supported on Docker Engine - Community on Ubuntu or Debian.

Prerequisites

btrfs is supported if you meet the following prerequisites:

• Docker Engine - Community: For Docker Engine - Community, btrfs is only recommended on Ubuntu or Debian.

• Changing the storage driver makes any containers you have alreadycreated inaccessible on the local system. Use docker save to save containers,and push existing images to Docker Hub or a private repository, so that younot need to re-create them later.

• btrfs requires a dedicated block storage device such as a physical disk. Thisblock device must be formatted for Btrfs and mounted into /var/lib/docker/.The configuration instructions below walk you through this procedure. Bydefault, the SLES / filesystem is formatted with BTRFS, so for SLES, you donot need to use a separate block device, but you can choose to do so forperformance reasons.

• btrfs support must exist in your kernel. To check this, run the followingcommand:

• To manage BTRFS filesystems at the level of the operating system, you need thebtrfs command. If you do not have this command, install the btrfsprogspackage (SLES) or btrfs-tools package (Ubuntu).

Configure Docker to use the btrfs storage driver

This procedure is essentially identical on SLES and Ubuntu.

1. Stop Docker.

2. Copy the contents of /var/lib/docker/ to a backup location, then emptythe contents of /var/lib/docker/:

3. Format your dedicated block device or devices as a Btrfs filesystem. Thisexample assumes that you are using two block devices called /dev/xvdf and/dev/xvdg. Double-check the block device names because this is adestructive operation.

   There are many more options for Btrfs, including striping and RAID. See theBtrfs documentation.

4. Mount the new Btrfs filesystem on the /var/lib/docker/ mount point. Youcan specify any of the block devices used to create the Btrfs filesystem.

   Don’t forget to make the change permanent across reboots by adding anentry to /etc/fstab.

5. Copy the contents of /var/lib/docker.bk to /var/lib/docker/.

6. Configure Docker to use the btrfs storage driver. This is required eventhough /var/lib/docker/ is now using a Btrfs filesystem.Edit or create the file /etc/docker/daemon.json. If it is a new file, addthe following contents. If it is an existing file, add the key and valueonly, being careful to end the line with a comma if it is not the finalline before an ending curly bracket (}).

   See all storage options for each storage driver in thedaemon reference documentation

7. Start Docker. After it is running, verify that btrfs is being used as thestorage driver.

8. When you are ready, remove the /var/lib/docker.bk directory.

Manage a Btrfs volume

One of the benefits of Btrfs is the ease of managing Btrfs filesystems withoutthe need to unmount the filesystem or restart Docker.

When space gets low, Btrfs automatically expands the volume in chunks ofroughly 1 GB.

To add a block device to a Btrfs volume, use the btrfs device add andbtrfs filesystem balance commands.

Note: While you can do these operations with Docker running, performancesuffers. It might be best to plan an outage window to balance the Btrfsfilesystem.

How the btrfs storage driver works

The btrfs storage driver works differently from devicemapper or otherstorage drivers in that your entire /var/lib/docker/ directory is stored on aBtrfs volume.

Image and container layers on-disk

Information about image layers and writable container layers is stored in/var/lib/docker/btrfs/subvolumes/. This subdirectory contains one directoryper image or container layer, with the unified filesystem built from a layerplus all its parent layers. Subvolumes are natively copy-on-write and have spaceallocated to them on-demand from an underlying storage pool. They can also benested and snapshotted. The diagram below shows 4 subvolumes. ‘Subvolume 2’ and‘Subvolume 3’ are nested, whereas ‘Subvolume 4’ shows its own internal directorytree.

Only the base layer of an image is stored as a true subvolume. All the otherlayers are stored as snapshots, which only contain the differences introducedin that layer. You can create snapshots of snapshots as shown in the diagrambelow.

On disk, snapshots look and feel just like subvolumes, but in reality they aremuch smaller and more space-efficient. Copy-on-write is used to maximize storageefficiency and minimize layer size, and writes in the container’s writable layerare managed at the block level. The following image shows a subvolume and itssnapshot sharing data.

For maximum efficiency, when a container needs more space, it is allocated inchunks of roughly 1 GB in size.

Docker’s btrfs storage driver stores every image layer and container in itsown Btrfs subvolume or snapshot. The base layer of an image is stored as asubvolume whereas child image layers and containers are stored as snapshots.This is shown in the diagram below.

The high level process for creating images and containers on Docker hostsrunning the btrfs driver is as follows:

1. The image’s base layer is stored in a Btrfs subvolume under/var/lib/docker/btrfs/subvolumes.

2. Subsequent image layers are stored as a Btrfs snapshot of the parentlayer’s subvolume or snapshot, but with the changes introduced by thislayer. These differences are stored at the block level.

3. The container’s writable layer is a Btrfs snapshot of the final image layer,with the differences introduced by the running container. These differencesare stored at the block level.

How container reads and writes work with btrfs

Reading files

A container is a space-efficient snapshot of an image. Metadata in the snapshotpoints to the actual data blocks in the storage pool. This is the same as witha subvolume. Therefore, reads performed against a snapshot are essentially thesame as reads performed against a subvolume.

Writing files

• Writing new files: Writing a new file to a container invokes an allocate-on-demandoperation to allocate new data block to the container’s snapshot. The file isthen written to this new space. The allocate-on-demand operation is native toall writes with Btrfs and is the same as writing new data to a subvolume. As aresult, writing new files to a container’s snapshot operates at native Btrfsspeeds.

• Modifying existing files: Updating an existing file in a container is a copy-on-writeoperation (redirect-on-write is the Btrfs terminology). The original data isread from the layer where the file currently exists, and only the modifiedblocks are written into the container’s writable layer. Next, the Btrfs driverupdates the filesystem metadata in the snapshot to point to this new data.This behavior incurs very little overhead.

• Deleting files or directories: If a container deletes a file or directorythat exists in a lower layer, Btrfs masks the existence of the file ordirectory in the lower layer. If a container creates a file and then deletesit, this operation is performed in the Btrfs filesystem itself and the spaceis reclaimed.

With Btrfs, writing and updating lots of small files can result in slowperformance.

Btrfs and Docker performance

There are several factors that influence Docker’s performance under the btrfsstorage driver.

Note: Many of these factors are mitigated by using Docker volumes forwrite-heavy workloads, rather than relying on storing data in the container’swritable layer. However, in the case of Btrfs, Docker volumes still sufferfrom these draw-backs unless /var/lib/docker/volumes/ is not backed byBtrfs.

Docker For Mac Slow Ext4 Partition Recovery Software

• Page caching. Btrfs does not support page cache sharing. This means thateach process accessing the same file copies the file into the Docker hosts’smemory. As a result, the btrfs driver may not be the best choicehigh-density use cases such as PaaS.

• Small writes. Containers performing lots of small writes (this usagepattern matches what happens when you start and stop many containers in a shortperiod of time, as well) can lead to poor use of Btrfs chunks. This canprematurely fill the Btrfs filesystem and lead to out-of-space conditions onyour Docker host. Use btrfs filesys show to closely monitor the amount offree space on your Btrfs device.

• Sequential writes. Btrfs uses a journaling technique when writing to disk.This can impact the performance of sequential writes, reducing performance byup to 50%.

• Fragmentation. Fragmentation is a natural byproduct of copy-on-writefilesystems like Btrfs. Many small random writes can compound this issue.Fragmentation can manifest as CPU spikes when using SSDs or head thrashingwhen using spinning disks. Either of these issues can harm performance.

  If your Linux kernel version is 3.9 or higher, you can enable the autodefragfeature when mounting a Btrfs volume. Test this feature on your own workloadsbefore deploying it into production, as some tests have shown a negativeimpact on performance.

• SSD performance: Btrfs includes native optimizations for SSD media.To enable these features, mount the Btrfs filesystem with the -o ssd mountoption. These optimizations include enhanced SSD write performance by avoidingoptimization such as seek optimizations which do not apply to solid-statemedia.

• Balance Btrfs filesystems often: Use operating system utilities such as acron job to balance the Btrfs filesystem regularly, during non-peak hours.This reclaims unallocated blocks and helps to prevent the filesystem fromfilling up unnecessarily. You cannot rebalance a totally full Btrfsfilesystem unless you add additional physical block devices to the filesystem.See theBTRFS Wiki.

• Use fast storage: Solid-state drives (SSDs) provide faster reads andwrites than spinning disks.

• Use volumes for write-heavy workloads: Volumes provide the best and mostpredictable performance for write-heavy workloads. This is because they bypassthe storage driver and do not incur any of the potential overheads introducedby thin provisioning and copy-on-write. Volumes have other benefits, such asallowing you to share data among containers and persisting even when norunning container is using them.

Related Information

Mac Slow Internet