Using the XFS filesystem in a Gitlab runner

We are adding a CI/CD stage to our pipeline to automatically run a set of important integration tests on the full system.

The thing is, this system must have access to a docker socket that has an overlay2 storage driver backed by an XFS filesystem. Our current approach is to use the docker in docker image, have xfsprog create an XFS formatted file, and then mount that file inside the container that the CI/CD job is running. Since the image is Docker in Docker, in theory the Docker daemon inside the image should then be able to be backed by that volume. The trouble is that mounting however does not work. I ran the following sequence of commands in a before_script:

    - apk update
    - apk add xfsprogs
    - touch xfs.bin
    - mkfs.xfs -d size=1g xfs.bin
    - mkdir /xfs
    - mount -o prjquota -t xfs xfs.bin /xfs

This works fine if I locally run the docker:24.0.5 image, however when I run this inside the CI/CD pipeline running on shared runners, I get:

mount: mounting /dev/loop0 on /xfs failed: Invalid argument

I am aware that I may be running into the limitations of GitLab Runners, especially the shared ones that we do not control, but is there any way to get this to work, or is there any way that we can get a docker daemon to be available to our application which is backed by XFS?

We are running with shared runners on an SaaS GitLab Ultimate instance.

The error message could mean that mounting a filesystem from within CI/CD might need elevated permissions, or the driver does not support it. Never tried mounting a device in CI/CD yet.

For this specific test requirement, I’d suggest trying a self-hosted GitLab Runner with specific Docker configuration for volumes and/or running privileged containers.

I have exactly the same need. I need XFS filesystem to be able to use file cloning and test it in our codebase. So is there some way to make this work on shared runners?

If you didn’t set up the runners then no. You would need to create your own runner with the XFS filesystem, and then do whatever you need to do. Your own runner at this point can be a dedicated runner for a project, or you can use it as a shared runner. Runners provided by Gitlab will not have that functionality and they are unlikely to configure them differently including settings related to docker and security restrictions.

1 Like

Thanks for the response. What about GitLab providing runners with xfs as the base file system to begin with on a fleet of runners? Then it would not be needed to have additional permissions?

Is there a place to open such a feature request?

You could try here: Issues · shared-runners · GitLab

1 Like