If done correctly there should be no errors and this should work. d4m-nfs.sh which uses the Shebang for what shell should run it.
![mac nfs slow mac nfs slow](https://cdn-media-1.freecodecamp.org/images/1*pH318KUH_V10gogDY13Nog.jpeg)
Restart docker and docker-compose down any containers as well.ĥ.) Finally navigate to the d4m-nfs directory we created in step 1 and type the following command, /bin/bash d4m-nfs.shĮdit The correct way to type the command above is this as another user from the github (if-kenn) pointed out. I mean nothing else it won't work if there is anything else since it will create conflicts with the NFS systems that the script will make for you later. Make sure only /tmp is showing and NOTHING ELSE. What the above does is allows you to still use relative folders with docker-compose and allows all ports to connect on it hence the 0:0.Ĥ.) Go to your docker preferences and do the following Users/yourusername:/Users/yourusername:0:0
MAC NFS SLOW CODE
To do this open up terminal and type cd ~Īlternatively you can also do this in a one liner git clone ~/d4m-nfsĢ.) Next go into the d4m-nfs folder and create a new file in the /etc folder and title it d4m-nfs-mounts.txtģ.) Add the following lines of code to this.
MAC NFS SLOW MAC
The key here is to understand this solution creates NFS (Network File System) drives as the means of communication from the Docker Containers to your Mac instead of the standard OSX File System which is very slow currently either due to bugs or the way it works*ġ.) Clone this repo here ( ) in your home directory. I doubt it matters, but it just struck me as an interesting question.Okay the user Spiil gave a solution but I wanted to elaborate on the exact steps to take since I went through 12 hours trying to figure it out, but once you know how its super easy and fixes all the slow down issues! If that makes a difference to your specific question, it could be because the globbing takes place in the shell, instead of ls, which might affect how the Ctrl-C is processed. So that seems an interesting line of investigation.ĮDIT: note that your example ls * is also a use of globbing. A mount of the same directory using the nordirplus option to disable the use of readdirplus calls, a glob on the same directory takes only 1.7 seconds.RHEL 6.2 with a standard mount, a glob in a directory containing over 3000 directories takes 218 seconds (nearly four minutes).RHEL6: NFSv3 READDIRPLUS drastically slows down globbing over a NFS directory leading to performance problems First result is a (paywalled) bug report. Googling for nfs readdirplus - this looks quite plausible. Instead of sending individual stat requests for each file. In other words there's one NFS call that basically does ls -l (for a certain number of files). Basically readdir + then stat for each file. Google found a list of NFS calls which includes READDIRPLUS. mount with intr option might allow Ctrl-C to interrupt the in-flight call. Way too much IO on the server side, causing a single NFS call to take >20s. Hypothesis: traversing a directory over NFS is speculatively loading more data than you would expect at once.
![mac nfs slow mac nfs slow](https://assets2.rockpapershotgun.com/nfsp08.jpg)
It's not even the shell's fault: it's NFS's fault.
![mac nfs slow mac nfs slow](https://s3.amazonaws.com/fullstackfeed/default-images/4.jpg)
It's not the fault of the ls command (which may not even have been started yet).
![mac nfs slow mac nfs slow](https://www.jeffgeerling.com/sites/default/files/drupal-page-load-vagrant-virtualbox-nfs-samba.png)
MAC NFS SLOW UPDATE
Even reading a file might update its access time. You can't interrupt a filesystem operation just anywhere, as this could leave the system in an inconsistent state. When you press Ctrl+ C, this won't interrupt the current NFS operation. The ls command looks up each file in turn and retrieves its metadata ( stat call) to check whether it is a directory if a file is a directory, ls lists its contents rather than the directory itself. Once the shell has obtained the list of names of files in the current directory, it sorts that list (which is very quick compared to any network interaction), then calls ls. If the directory is huge and the server is slow, this could take a while. When you run ls *, the first thing that happens is that the shell obtains a listing of the current directory.