A key difference is that the file system contents is preprocessed into content-addressable storage (somewhat similar to the format in a .git folder). Also a number of features and optimizations to make it work well as a shared software area, which is characterized by many small, often memory-mapped files and a meta-data heavy access pattern.
The data is not part of the images. It's only the software. In the vast majority of cases, any particular data processing job requires only a tiny fraction of the available software. For instance, a few hundred MB out of a few tens of GB for a typical LHC application software release.
In practice that sounds like an excellent optimization, but in theory it annoys me that we're doing that rather than figuring out how to build better binaries.
I work on a platform that handles fleets of edge devices running a linux-based OS, where applications are distributed as container images. Nvidia in particular are rather awful to support, as any users with their hardware inevitably build 10+ GB images, largely composed of libraries and samples they'll never use. Plenty of other users are unaware that they can improve the speed and reliability of their deployments by trimming the fat from their images.
A lot of work goes into properly handling and optimizing the download and distribution of excessively large application images, often on slow and unreliable networks, when smaller is always faster and more reliable.
The project started around 2007/2008 and produced a virtual machine image to run LHC experiment applications in the cloud. In order to keep image sizes manageable, we looked into network file systems that could distribute the application software (including AFS/Conda, HTTP-FUSE [1], Igor-FS [2], GROW-FS [3]). None of them ticked all the boxes, so we developed CernVM-FS (CVMFS), which then developed a life beyond CernVM.
