Unioning file systems: Architecture, features, and design choices

You have a basic set of packages (aka "the base system") preinstalled into a special location which you when union mount with (initially empty) container COW/private area. Then a container wants to change any file a private COW copy is created. This setup allows for:
1. Fast container creation — all the files are already there, you only have to mkdir and mount.
2. Sharing files on disk; ideally you need N times less space where N is number of containers you have.
3. Sharing pages in memory; whenever the library/binary/mmap'ed file used from different containers is the same on disk (i.e. device and inode are the same) there will be only one copy of its read-only data in memory.

In practice benefits from #2 and #3 can only be achieved if containers are identical (same distro, same exact versions of same packages), and will deteriorate over time when you modify files from inside those containers (like when you run 'yum update' in both you may end up with same packages being updated but now their files are in COW areas — this is yet another problem to deal with).