You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prior to upgrading to 3.3.0, running a command in a container that mounted a host file system took a very similar length of time as running the same container without mounting the files.
Actual behavior
The container has a rails server in it:-
time docker run -ti --rm <container> rake --tasks real 0m6.962s user 0m0.115s sys 0m0.067s
Same container mounting the identical rails source tree from a host directory:-
time docker run -ti -rm --mount type=bind,source="$(pwd)/rails",target="/home/hosting/rails" <container> rake --tasks real 2m17.010s user 0m0.135s sys 0m0.068s
This makes it impossible to deploy a stack that mounts an editable source tree.
Information
This is reproducible on demand. A coworker using an M1 mac has the exact same problem.
During the huge time difference between the two cases, the hyperkit CPU usage stays over 300-400% in the activity monitor.
This is a new problem
The problem appeared when we updated to 3.3.0
macOS Version: 11.2.3
Intel chip or Apple chip: 3.2 GHz 6-Core Intel Core i7
Docker Desktop Version: 3.3.1 (63152)
Steps to reproduce the behavior
Run a rails command in a container that mounts the rails source tree.
There is something about how Rails accesses the files during startup that seems to be making it behave so badly in these recent versions.
If needed, I'll try and create a simple container to reproduce this.
The text was updated successfully, but these errors were encountered:
Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so.
Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale
Expected behavior
Prior to upgrading to 3.3.0, running a command in a container that mounted a host file system took a very similar length of time as running the same container without mounting the files.
Actual behavior
The container has a rails server in it:-
Same container mounting the identical rails source tree from a host directory:-
This makes it impossible to deploy a stack that mounts an editable source tree.
Information
Steps to reproduce the behavior
The text was updated successfully, but these errors were encountered: