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 volume/
directory.
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 volumes.img
and volumes/
.
Note that 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 btrfs
(https://github.com/concourse/concourse/issues/4071)