From c12f6206ffeb1774cdbd6f1710859422536a4f98 Mon Sep 17 00:00:00 2001 From: paigehargrave Date: Fri, 11 Jan 2019 15:46:04 -0500 Subject: [PATCH] Update osxfs.md --- docker-for-mac/osxfs.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docker-for-mac/osxfs.md b/docker-for-mac/osxfs.md index 5df2636310..02e3bfac3f 100644 --- a/docker-for-mac/osxfs.md +++ b/docker-for-mac/osxfs.md @@ -6,14 +6,14 @@ redirect_from: title: File system sharing (osxfs) --- -`osxfs` is a new shared file system solution, exclusive to Docker for Mac. +`osxfs` is a new shared file system solution, exclusive to Docker Desktop for Mac. `osxfs` provides a close-to-native user experience for bind mounting macOS file system trees into Docker containers. To this end, `osxfs` features a number of unique capabilities as well as differences from a classical Linux file system. ### Case sensitivity -With Docker for Mac, file systems operate in containers in the same way as they +With Docker Desktop for Mac, file systems operate in containers in the same way as they operate in macOS. If a file system on macOS is case-insensitive, that behavior is shared by any bind mount from macOS into a container. @@ -31,7 +31,7 @@ on case-insensitivity to function. ### Access control `osxfs`, and therefore Docker, can access only those file system resources that -the Docker for Mac user has access to. `osxfs` does not run as `root`. If the macOS +the Docker Desktop for Mac user has access to. `osxfs` does not run as `root`. If the macOS user is an administrator, `osxfs` inherits those administrator privileges. We are still evaluating which privileges to drop in the file system process to balance security and ease-of-use. `osxfs` performs no additional permissions @@ -160,7 +160,7 @@ between macOS userspace processes and the macOS kernel. With regard to reported performance issues ([GitHub issue 77: File access in mounted volumes extremely slow](https://github.com/docker/for-mac/issues/77)), -and a similar thread on [Docker for Mac forums on topic: File access in mounted +and a similar thread on [Docker Desktop for Mac forums on topic: File access in mounted volumes extremely slow](https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/), this topic provides an explanation of the issues, recent progress in addressing @@ -176,7 +176,7 @@ mentioned. We want to surface it in the documentation for wider reach. Perhaps the most important thing to understand is that shared file system performance is multi-dimensional. This means that, depending on your workload, you may experience exceptional, adequate, or poor performance with `osxfs`, the -file system server in Docker for Mac. File system APIs are very wide (20-40 +file system server in Docker Desktop for Mac. File system APIs are very wide (20-40 message types) with many intricate semantics involving on-disk state, in-memory cache state, and concurrent access by multiple processes. Additionally, `osxfs` integrates a mapping between macOS's FSEvents API and Linux's `inotify` API @@ -207,7 +207,7 @@ haven't implemented all those improvements yet (more on this below in [What you can do](osxfs.md#what-you-can-do)). A second approach to improving performance is to reduce the number of -roundtrips by caching data. Recent versions of Docker for Mac (17.04 onwards) +roundtrips by caching data. Recent versions of Docker Desktop for Mac (17.04 onwards) include caching support that brings significant (2-4×) improvements to many applications. Much of the overhead of osxfs arises from the requirement to keep the container's and the host's view of the file system consistent, but @@ -310,7 +310,7 @@ can be easily tracked. #### What you can expect We continue to work toward an optimized shared file system implementation -on the Edge channel of Docker for Mac. +on the Edge channel of Docker Desktop for Mac. You can expect some of the performance improvement work mentioned above to reach the Edge channel in the coming release cycles. @@ -330,7 +330,7 @@ We hope this gives you a rough idea of where `osxfs` performance is and where it's going. We are treating good performance as a top priority feature of the file system sharing component and we are actively working on improving it through a number of different avenues. The osxfs project started in December -2015. Since the first integration into Docker for Mac in February 2016, we've +2015. Since the first integration into Docker Desktop for Mac in February 2016, we've improved performance by 50x or more for many workloads while achieving nearly complete POSIX compliance and without compromising coherence (it is shared and not simply synced). Of course, in the beginning there was lots of low-hanging