Incidentally, I’ve been working on a series of blog posts to explain the different storage driver options in Concourse so this information is fresh in my mind.
By default, Concourse tries to automatically select the “best” available storage driver option for managing volume and container storage. If the Concourse worker hosts support the
btrfs Linux filesystem driver, Concourse will use this
btrfs functionality. Now, in many cases, while the host where the Concourse is installed may support the
btrfs Linux filesystem driver, the filesystem that Concourse’s worker directory is installed on may be a different filesystem (e.g.
ext4). In this situation, Concourse will still try to leverage the
btrfs filesystem features, by creating a
btrfs filesystem on a loop device. The underlying storage of this loop device is
volumes.img, and it’s mounted at the worker’s
Going forward, Concourse (more specifically, the
baggageclaim component behind the scenes) uses the loop device to manage image/container storage, and is able to leverage
btrfs features for efficient copy-on-writes. Concourse sizes
volumes.img so that it will take up all but 10GB of the disk space of the disk its installed on.
Thus, if the worker is still in use, you probably shouldn’t touch
volumes.img. However, if you do want to try cleaning it up, you’ll need to unmount the loop device before removing
btrfs is a “real” filesystem dealing with block devices, which is why Concourse needs to create the loop device in the first place. So another thing you could try is to install Concourse on a
btrfs filesystem - this would remove the intermediate loop device step, and then Concourse would be able to use the
btrfs file system features directly.
As for the disk space issue - unfortunately, I don’t have any other solutions for handling it.
edit: Concourse may be soon changing it so that
overlay is the default instead of