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)
