Hi Oliver,

Generally, each unique ISC_DATA_DIRECTORY should be bound to one persistent instance.  If you have two instances you wish to maintain, IRIS1 and IRIS2, they should each have their own unique persistent storage location.  There's nothing preventing you from putting both of them on the same EFS store, as long as that point to different, unique directories within that store.  So your idea of an individual directory tree for each container should work just fine.  (Exception: If you are using mirroring for availability, I would not recommend storing both/all parts of a given mirror set on the same EFS store.)  Two simultaneously running containers/instances should never be pointing at the same mgr/IRIS.DAT, that will not result in a functional application.

I say persistent instance because you can freely stop a container, and then start a new one with the same ISC_DATA_DIRECTORY and have a new container - possibly with a newer version of InterSystems IRIS, or a newer version of your code - run on the same persisted data.

Additionally: Depending on your particular needs, you may not wish to use EFS for ISC_DATA_DIRECTORY locations.  EFS is an NFS implementation, which has been known to cause problems with container runtime engines, and EFS will generally have higher disk latency than other things, EBS might be one better choice.  Consult AWS documentation to be sure!  https://docs.aws.amazon.com/efs/latest/ug/performance.html

This is an interesting hack, but I can't recommend using Docker for Windows or Mac.  There's some detail on this in Shakespeare on Linux Containers, and @Rich Taylor did a great job of laying out the basics.  If you have the ability to run your own Linux VM, I recommend it - and it looks like you're already working on this, which is great!

The file ownership problem on Windows bind mounts can't be fixed, Windows doesn't have user/group/world permissions like Unix does, and it doesn't understand your Linux uids.  Even when we avoid that, the CIFS mechanism used to expose Windows folders into your container doesn't support all the different fsync() options needed to guarantee journal durability.  I don't know for sure, but I think the fsync problem is the reason that every written-to-disk DBMS that runs in containers has the advice of "when running on Docker for Windows, use a named volume and not a bind mount."