Singularity中mount与bind的区别及bind mount相关疑问

Great question! Let's break this down clearly—these concepts are crucial for working with Linux filesystems and containers, so it's good to get the details straight.

1. Core Differences Between Traditional mount and Bind Mounts #

First, let's clarify what each does, then highlight their key distinctions:

Traditional mount #

The standard mount command is used to attach an entire filesystem (like a physical disk partition, ISO image, or special kernel-managed filesystem) to a directory (the "mount point") in your system's directory tree. For example:

mount /dev/sda1 /mnt/external-drive  # Mount a physical storage partition
mount -t tmpfs tmpfs /mnt/temp-memory # Mount a temporary in-memory filesystem

It typically requires specifying (or auto-detecting) the filesystem type and works with block devices or filesystem images as the source.

Bind Mounts #

Bind mounts are a special use case of the mount command (enabled via the --bind option) that lets you attach an existing file or directory (from an already mounted filesystem) to another location. Think of it as creating a "mirror" access point for the original file/directory. Example:

mount --bind /home/john/data /container/data  # Share a host directory with a container
mount --bind -o ro /etc/hosts /tmp/hosts-readonly  # Mount a single file as read-only

Key Distinctions

• Source Type: Traditional mount uses full filesystems (block devices, images); bind mounts use existing files/directories from already mounted filesystems.
• Filesystem Type: Traditional mount needs a filesystem type (e.g., ext4, tmpfs); bind mounts don't—they reuse the source's filesystem properties.
• Granularity: Bind mounts can target individual files (not just directories), which traditional mount can't do easily.
• Sync Behavior: Changes to the source or bind mount location affect both, since they point to the same underlying filesystem object (same inode).

2. Ideal Use Cases for Each #

Traditional mount #

• Mounting physical storage: Attach external drives, internal partitions, or network storage (like NFS) to your system for regular access.
• Special kernel filesystems: Mount proc, sysfs, or tmpfs to access kernel runtime information or use fast, temporary in-memory storage.
• Disk/ISO images: Mount CD/DVD ISOs or disk images to access their contents without burning or restoring them to physical media.

Bind Mounts #

• Containerization: Share specific host files/directories with containers (this is exactly what Singularity/Docker use for volume sharing to let containers access host data).
• Temporary configuration testing: Mount a new config file over an existing one to test changes without replacing the original file permanently.
• Permission management: Mount a directory as read-only (-o ro) to restrict modifications, even if the original directory is writable.
• Directory restructuring: Move a directory to a new location temporarily by binding it to the old path, while updating application configurations in the background.

3. Is Singularity's Default Bind Mount Mechanism Real? #

Absolutely—this is a well-documented, default behavior of Singularity (now part of Sylabs SingularityCE) built to align with HPC (High-Performance Computing) user workflows.

The default binds include:

• /home/$USER: Your host home directory, so you can access your personal files directly in the container without extra setup.
• /tmp: The host's temporary directory, allowing shared temp files between the host and container.
• $PWD: Your current working directory on the host, so you can run commands on files in your current location without navigating elsewhere in the container.

If you want to disable this behavior, you can use flags like --no-mount home,tmp,pwd to skip specific binds, or --cleanenv to start with a minimal environment without these mounts. This is a key difference from Docker, which requires explicit -v flags to share host directories.

内容的提问来源于stack exchange，提问作者Monica Heddneck