We'd love to get your feedback on the new filesystem engine in the Docker for Mac app. It's been a ton of work to get right, and there a few corner cases in the current beta that we're squashing, but overall things "just work" for my day-to-day Linux development on my Mac using the current beta.

At this stage, pointing it to the weirdest and most wonderful filesystem stressers you can find is welcome. We'll leap on any issues you find...

One thing I'm immediately concerned about is having some way of "pausing" xhyve. Purely because of Android development :(

Intel's HAXM doesn't (seem to?) play nice, and asks for an exclusive lock. See https://github.com/mist64/xhyve/issues/88 and https://code.google.com/p/android/issues/detail?id=197915

You can quit and restart (its very quick). There isn't a pause at present though.

That's probably good enough

I haven't tried the Android emulator recently, but I am interested in deploying Facebook's Infer tool on our codebase (and they've got a Docker container too for it of course). So I've filed an internal bug for us to look into HAXM and figure out if it plays well with Docker for Mac/Windows. Thanks for the pointer!

What is the filesystem engine? Is it just something fancy on top of NFS, or something completely new?

It's something new.

Is it related to the work started by Brad Fitzpatrick a few months ago with the goal of implementing client-server gateway between the host and the guest filesystem using FUSE?

The new daemon (dubbed osxfs) is FUSE-based at the moment, but also provides a semantic translation layer between OSX filesystem calls and Linux kernel events. The FUSE layer can be removed in the future in favour of a direct kernel module with this architecture, if it ends up being a bottleneck (its fine right now though)

Do you use a custom protocol between the daemon running in OSX and the one running in the container?

Is there some kind of caching? If yes, what is the impact on tools like make when checking atime or mtime? If no, is there a perceptible impact on latency, for example when compiling a large project in the container?

I gotta say I've had about all the VirtualBox I can take in this lifetime. It's caused me pretty dire file handling problems on 3 projects and only 2 of those had any Docker in them. Thanks for working on this.

I have an open bug against docker-compose (docker doesn't do the same thing by itself) where the wrong layers are being used, but only on virtualbox.

Hopefully this will solve that problem, as well as how to make my dev and prod database handling more homogenous. And I can finally turn sendfile back on in my nginx configs without having to special case anything for dev!

Is this using the normal VirtualBox "shared folders" functionality? For Vagrant we had to drop VirtualBox in favour of VMware Fusion because VirtualBox suffered cache corruption almost every day. You would write a file on the host, and the file would be corrupt inside the VM. Last I checked, this bug was still open, but I'm not certain (on my phone right now), but it still makes me wary of using VirtualBox again. Have you dealt with this issue at all?

Edit: Or is this not using any VirtualBox code at all?

No it does not use any virtualbox code.

I've been running Docker on Hyper-V since the start (VBox never worked for me as I had a requirement on Hyper-V) - can you provide a little more info on how unikernel experience was used to make a difference? Is this a custom compiled linux kernel with Alpine distro on top? How would volume mounts compare to something like using the netshare (cifs) with a samba share from the windows host? (which is what I'm currently using)?

I really appreciate you guys working on that. I have since moved to a debian VM, but might eventually move back if I don't need to frequently restart docker machine hosts.

Will do, I've signed up for the beta (same username as here)

What is the performance of this new filesystem engine, compared to VirtualBox shared folders, which are well-known to be slow?

This is huge! We had a lot of trouble getting fs notifications working in containers, especially for hot-reloading of code.

Our solution was to create a custom fs watcher that would look for changes in the content of the files (it's only code, and for development, so speed doesn't matter much). I have been looking to replace this with something cleaner (at least with something like Dinghy and actual filesystem events), but Docker for Mac is likely the way we'll go.

Anywhere I see Docker on Mac mentioned, I always point people to Dinghy. It has solved a lot of the issues the vanilla solutions had (NFS, fsevents etc) and the maintainer is incredibly responsive.

I would love to see Docker come up with something that rivals Dinghy as I would prefer not to have to use a third party tool, but considering their reputation for stability and the comments being made about xhyve, I am happy to continue using (and gushing about) Dinghy for the foreseeable future.

You should check out Dlite (which is an alternative to Dinghy) has been around for a few months: https://github.com/nlf/dlite

It's been a much more friendly (read: plugin and play) than dinghy.

As mentioned in another comment here [1], we've been in touch with the author of dlite during this beta. His feedback was very useful!

[1] https://news.ycombinator.com/item?id=11352621

Does it mean no `VBox shares` mmap bug limiting the use of volumes in Cassandra and MongoDB containers?

Yes that should work fine with osxfs (the new filesystem engine). Do you have a pointer to the specific bug in vbox so we can add it to our test suite?

Here [1], under "WARNING (Windows & OS X)", there're several links to bug reports on VBox and Mongo trackers.

[1] https://hub.docker.com/_/mongo

Here is the catch: you just need to realise that docker-machine is really just a virtual box linux machine. Once you get that, having shared volumes working as expected is quite easy without requiring 3rd party tools. I'm actually quite concerned on how this is going to change with this new tools, if they introduced "more magic" it could mean to lose control on your local environments.

In my comment I wanted to express the same, the whole Boot2docker solution seem too hacky for non Docker enthusiastic devs. I had hard time trying to convincing co-workers to use docker for development environment, mainly because filesystem, and the user experience. You have to really like docker to go thru all the setup. I did it but I can see why my coworkers didn't.

Agreed. We gave up on it and created a local beefy server that we shared for docker testing, but then we have port collisions and the other problems that come along with sharing.

Native is better and I'm very excited for this.