

Being able to control volume mounts on these different modes is crucial to achieving maximum performance.

Consistency also probably isn't required for these artifacts directories, it just needs to be "generally there". We'd also need to control whether the host or container is alpha or beta. I believe the "one way" is more performant than "two way" since it only needs to check the filesystem changes in one direction. Mutagen offers different modes and ideally we should have access to all of these modes. Magento 2 seems to be an ideal use-case to test the folder sync issues. I wrote a blog post about all of this at which may be useful to others dealing with filesystem performance issues. As a developer you want assets like these to be generally available, and don't want to have to worry about this folder becoming "out of sync" with the host. should basically persist on the container, however the issue that pointed out that you miss IDE functionality is definitely valid. performance (outright speed), but it's a tightrope.Īrtifacts and caching directories like var/cache, generated, node_modules, vendor, etc. Most places I know are still using NFS, with polling, and trying to tune the fsattr cache times to get a reasonable balance of developer experience (speed of code reloading) vs. None of the existing methods account for this very well, even the relatively new mount options to try and performance boost either reads or writes don't particularly help because of the relative symmetry under certain configurations. I hope leaving a note here is not unwelcome to highlight a particular difficulty in booting Rails applications in Docker on macOS.īetween Rails hot code reloading, which has a semi-hard dependency on working filesystem events (the polling alternative can eat as much as 20% of system CPU) and Bootsnap, which is a caching loader which tries to speed up booting Rails by bypassing the parsing step (and caching compiled btyecode on disk) which means that booting a Rails app with bootsnap loaded writes as many file as it reads (sometimes), but other times (e,g warm start) has a very different read/write ratio.
