Add options to control the consistency of the source mount

[shi-yan]

on mac, the workspace folder doesn't seem to be mounted with consistency=cached

this causes low io performance

see https://stories.amazee.io/docker-on-mac-performance-docker-machine-vs-docker-for-mac-4c64c0afdf99?gi=ab8ea7964793

for details.

docker run --mount src="$(pwd)/../../myproj",target=/work/myproj,type=bind,consistency=cached

[chrmarti]

Not sure if cached will be a safe choice for all workloads. Marking as feature request for now.

In the meantime you could used a Docker Compose file to control all options.

[shi-yan]

I agree it shouldn't be a choice for all workloads, I think it should be an option user can set.

But without it, the performance is so bad on mac, it is barely usable. you could try building a large c++ program and compare it with the native performance.

[chrmarti]

I have seen the best performance when using a volume mount and checking out the source there. You can do that and/or control the consistency by using a Docker Compose file: https://code.visualstudio.com/docs/remote/containers#_using-docker-compose

[egamma]

I have seen the best performance when using a volume mount and checking out the source there.

@chrmarti @Chuxel suggest to document this in tips & tricks?

[shi-yan]

so I have tried docker compose, somehow, vscode got stuck at the "creating container" stage. the container was created, as I was able to see it with docker container ls. there is no additional info for me to debug.

[chrmarti]

@shi-yan What's in the Dev Container terminal when it gets stuck?

[Chuxel]

I have seen the best performance when using a volume mount and checking out the source there.
@chrmarti @Chuxel suggest to document this in tips & tricks?

@egamma @chrmarti We could add this in, but VS Code would still volume mount the project using -v as well and use that as the working directory. It might cause more confusion than it would help. If the workspaceFolder property worked in the non-compose case, we could redirect it, but it does not.

[shi-yan]

@chrmarti this is all the output I saw from the terminal:
`Setting up container for folder: /Users/shiyan/xxx

Run: docker-compose -f /Users/shiyan/xxx/docker/docker-compose.yml up -d --build

Pulling ide (ubuntu:)...

latest: Pulling from library/ubuntu

Recreating docker_ide_1 ... done`

vscode got stuck at this point. the progressbar keeps loading, even it says recreating docker_ide_1 ... done.

manually checking all containers, I could see docker_ide_1 being created.

[chrmarti]

@shi-yan Is the "service" property in your devcontainer.json pointing at an existing service? (Could be #102.)

[shi-yan]

could be, I don't remember I set it. I will try again when I get back home. Thanks!

[shi-yan]

@chrmarti , yes, the issue is indeed #102, adding "service" resolved it.

[chrmarti]

Thanks @shi-yan. Keeping this issue for the consistency option.

[chrmarti]

Adding "workspaceMount" to override the default mount.

[connorshea]

How do you use workspaceMount? Is it just the literal args?

[Chuxel]

@chrmarti I don't think this particular case is fixed yet. We'd realistically need to support ${workspaceFolder} to get this to work. Unfortunately ${env:PWD} is going to be where VS Code starts, not the workspace location.

This works:

     "workspaceFolder": "/workspace",
    "workspaceMount": "src=/absolute/path/to/where/source/code/is/on/host,dst=/workspace,type=bind"

This doesn't:

     "workspaceFolder": "/workspace",
    "workspaceMount": "src=${workspaceFolder},dst=/workspace,type=bind"

The remote case is supported, but this one requires an absolute path as things are now which really isn't workable - we could close in favor of #306, but it seems to bump up the priority of that one to me at least.

[chrmarti]

Tracking in #442, so we can test and verify this independently.