2

I have an issue I’m looking to get some feedback on the correct “docker” way to resolve. I believe this is Docker for Mac specific because of the fact bind mounts use osxfs and the inodes are 64-bit, not 32-bit. Unlike filesystems like cifs which allow the use of ‘noserverino’, osxfs does not seem to have a way to let the client determine inodes rather than the mounted system.

I have created a basic docker image based on Ubuntu 16.04

    FROM ubuntu:16.04@sha256:ea1d854d38be82f54d39efe2c67000bed1b03348bcc2f3dc094f260855dff368

    RUN dpkg --add-architecture i386
    RUN apt-get update && apt-get install -y \
      bzip2 \
      expect \
      file \
      gtk2-engines-murrine:i386 \
      libgtk2.0-0:i386 \
      libxtst6:i386 \
      lib32stdc++6 \
      libxt6:i386 \
      libdbus-glib-1-2:i386 \
      libasound2:i386 \
      make \
      maven \
      openjdk-8-jdk \
      patch \
      python \
      rsync \
      swig \
      unzip \
      vim \
      wget \
      && rm -rf /var/lib/apt/lists/*

The purpose of this image is to server as a common build environment for developers. It also includes a commercial cross-compiler for an older 32-bit embedded device. For the purposes of this explanation, the docker image is named ‘crosscompiler’

Using Ubuntu (16.04 specifically) has been no issue for developers in a Virtual Machine form, but the many benefits of Docker outweigh the VM approach. So this Docker image is to replace the VM.

So the PROBLEM: Because the cross-compiler is a 32-bit toolchain it relies on i386 libraries to be included, which I’ve included in the above Dockerfile.

To use this image to compile code we might run something like the following:

docker run --rm -ti --volume=/path/to/source/code/to/build:/root/workspace crosscompiler /bin/sh -c “cd /root/workspace && ./build.sh”

build.sh runs a script that builds all of the code. The issue is that because this is a 32-bit cross compiler that does things like stat (which in our older cross-compiler does not have support for Large Files; i.e. 64-bit inodes). When the Ubuntu container mounts the hosts directory containing source code the inodes are all 64-bit and the 32-bit GNU Tools sees these files as Value too large for defined data type. Currently, I don't know of any way to tell osxfs (i.e. the macOS filesystem sharing used with Docker for Mac).

What would be the suggested way to resolve something like this?

  • Copy our source to the container that is spun up each time?
  • Somehow use Docker ‘Volumes’ so that the container builds the files itself?
  • Some way to configure a ‘noserverino’-like mount for osxfs?
  • Other options?

The goal here is to allow for local source code changes on the host to be easily compiled within the container. This will be used locally or on a Continuous Build environment so it is advantageous to come up with an elegant and sustainable solution.

1

Encountered similar problem lately. In order to workaround this issue, I've tried to mount my workspace as a 32-bit nfs volume by following the instructions in this article with some tweak. I changed nfsvers mount option to 2 to make sure the file system is 32-bit (inode).

Here is the snippet of docker-compose.yml for your reference.

  workspace_nfs:
    driver: local
    driver_opts:
      type: nfs
      o: "addr=host.docker.internal,rw,nolock,hard,nointr,nfsvers=2"
      device: ":${PWD}"

Hope this help.

| improve this answer | |
  • Thanks @james-chen, I am not working on this project anymore but this looks like a great solution. I can't 100% confirm it but it def looks like it will solve the issue I was having. I'm going to accept it and hope it helps others. – Adam H Jun 4 at 14:49
  • I can confirm that this does indeed fix the issue. – Gigo Jun 23 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.