Mounting in Operating Systems

The note is generated by CatDesk.

What Is Mountg?

Unix-like operatg systems (Lux, macOS, BSD), mountg (挂载) is the process of attachg a file system — whether it lives on a physical device, a network share, or a virtual disk image — to a specific directory the existg directory tree. That directory is called the mount pot. Once mounted, the contents of the file system become accessible as ordary files and directories under the mount pot.

The key sight is that Unix uses a sgle unified directory tree rooted at /. Unlike Wdows, which assigns a drive letter (e.g., D:\) to each volume, Unix tegrates all storage to one hierarchy. Mountg is the mechanism that makes this possible.

How It Works

1. The kernel receives a mount request — either at boot (via /etc/fstab) or at runtime (via the mount command or an automounter).
2. The kernel associates the file system with the mount pot directory. From that moment on, any path that descends to the mount pot is served by the mounted file system, not by whatever was previously under that directory.
3. Processes access files normally — they don’t need to know (or care) which underlyg device is volved. The Virtual File System (VFS) layer abstracts this away.

Common Examples

Unmountg

The reverse operation is unmountg (卸载), performed with umount (note: not “unmount”):

1

umount /mnt/usb

You cannot unmount a file system that is “busy” — i.e., if a process has an open file or its workg directory side the mount pot. Use lsof +D /mnt/usb or fuser -m /mnt/usb to fd what’s holdg it open, or use umount -l (lazy unmount) as a last resort.

macOS Specifics

On macOS, external drives and disk images are automatically mounted under /Volumes/. The diskutil command is the preferred high-level tool:

1
2
3
4

diskutil list                # show all disks and partitions
diskutil mount /dev/disk4s1  # mount a specific partition
diskutil unmount /Volumes/MyDrive
diskutil eject /dev/disk4    # unmount + physically eject

/etc/fstab — Persistent Mounts

On Lux, file systems that should be mounted automatically at boot are declared /etc/fstab:

# <device>       <mount pot>  <type>  <options>       <dump> <pass>
/dev/sda1        /              ext4    defaults        0      1
/dev/sdb1        /data          xfs     noatime         0      2
server:/share    /mnt/nfs       nfs     defaults,_netdev 0     0

Each field specifies the device, where to mount it, the file system type, mount options, and fsck order.

Key Concepts

• Bd mount: Mount an existg directory at another location (mount --bd /src /dst). Useful contaers and chroot environments.
• Overlay mount: Layer multiple directories on top of each other (used heavily by Docker for image layers).
• Automount: Systems like autofs or systemd-automount mount file systems on demand when the mount pot is accessed, then unmount after a period of activity.
• Mount namespaces: A Lux kernel feature (used by contaers) that gives each process group its own view of the mount table, providg isolation.

Why This Matters

Understandg mountg is fundamental to workg with Unix-like systems. It explas why USB drives appear under /Volumes/ or /media/, why Docker contaers have isolated file systems, why you get “device is busy” errors, and how network storage tegrates seamlessly to the local directory tree. The entire design philosophy of “everythg is a file” depends on the ability to graft arbitrary file systems to the unified namespace via mountg. $a$

$$a$$

$$a$$

$$\frac{a}{b}$$

$$s$$

A Random Story: The Last Unmount

The night the cluster died, Mara was eatg cold noodles at her desk.

She heard it before she saw it — a low, electronic sigh ripplg through the server room, like a thousand hard drives exhalg at once. Then the monitorg dashboard turned red. Not the polite amber of a warng, but the full, arterial red of catastrophe.

FATAL: cannot unmount /data — device is busy

She had seen that error a thousand times. Some careless process, some zombie shell left open by a colleague who’d gone home hours ago. Easy fix. Except this time, /data held the only copy of six months of climate simulation data, and forty seconds the power would cut for emergency matenance.

Mara dropped her chopsticks.

1

$ lsof +D /data

The output scrolled for what felt like forever. There — PID 31337. A Python process. Owner: root. Started: two hundred and twelve days ago.

She stared at it. Two hundred and twelve days. That process had been runng longer than she’d worked here.

1

$ kill -9 31337

Operation not permitted.

Of course. She wasn’t root. She typed furiously, hands shakg, huntg for someone — anyone — with sudo access still logged . The cluster admistrator was on a flight. The sysadm lead was at his daughter’s birthday party. She had thirty seconds.

Mara made a decision she would spend the next week justifyg writg.

She pulled the power cable herself.

The data survived. The file system had been clean enough that fsck recovered everythg on the next boot. The Python process — a rogue simulation that someone had forgotten to kill April — was gone.

Later, the cluster adm explaed what had happened: the process had opened a file descriptor to /data/results/fal.hdf5 and simply never closed it. No writes, no reads. Just held it. Like a hand on a door, keepg a room occupied long after everyone side had left.

“Mountg,” the adm said, pullg up the kernel source on his laptop, “is an act of trust. The kernel trusts that what you attach, you will eventually detach. Every open file is a promise to close it.” He paused. “That process made a promise April. And kept it — technically — until you pulled the plug.”

Mara looked at the recovered fal.hdf5. Six months of data. tact.

“Sometimes,” she said, “the only clean unmount is a hard reset.”

The adm nodded slowly. “That’s not the man page,” he said. “But it should be.”

A Second Random Story: The Cartographer of /mnt

Nobody remembered who had mounted the drive at /mnt/felix.

It showed up one Tuesday the df output — a 2.3 TB volume with no entry /etc/fstab, no correspondg device /dev, and a used-space count that ticked upward by exactly one kilobyte every seventeen mutes, whether or not anyone was writg to it.

Dmitri, the junior sysadm, found it first. He ran mount | grep felix and got back:

tmpfs on /mnt/felix type tmpfs (rw,nosuid,nodev,noexec)

tmpfs. A RAM disk. Which meant it lived entirely memory. Which meant it couldn’t possibly be persistg across reboots. Except the server logs showed it had been there, unterrupted, for four years, three months, and eleven days — predatg the current hardware by two years.

He told his manager. His manager told him to leave it alone.

Dmitri did not leave it alone.

He ls’d the directory. side was a sgle file: map.txt. He opened it.

It was a map — hand-drawn ASCII, lovgly detailed — of a city that did not exist. Streets named after system calls. A river labeled PIPE. A park called ode Gardens. the center, a small square marked simply: here.

He scrolled. The map was enormous. Thousands of les. It showed districts, alleyways, a harbor, a lighthouse at the edge of the prtable character set. And the margs, a small font-like arrangement of dots and dashes, annotations:

The bus depot was rebuilt 2.6.18.
The market burned down when they deprecated the old scheduler.
Nobody uses the lighthouse anymore, but the light still runs.

Dmitri sat back. Four years. Growg by exactly one kilobyte every seventeen mutes. Someone — somethg — was writg this map. Contuously. RAM that shouldn’t survive reboots. On a filesystem that had no source device.

He did the only reasonable thg: he opened a new termal and typed:

1

$ echo "Who are you?" >> /mnt/felix/map.txt

Seventeen mutes later, one kilobyte appeared. He opened the file.

The new content was a small addition to the map — a ty buildg on a street called std, with a door drawn > characters, and above it, a sign:

A VISITOR
(rare)
welcome.

Dmitri stared at the screen for a long time.

Then he got up, made coffee, came back, and started readg from the begng. He had four years of cartography to catch up on. The city had a lot of streets. He had time.

He never did fd out what was writg to it. But every seventeen mutes, for the rest of his time at that company, he would glance at the clock — and wonder what new alley had just been drawn.

When he left, he wrote one last le to map.txt:

1

$ echo "I have to go now. The city is beautiful." >> /mnt/felix/map.txt

He gave his notice the next day. On his last afternoon, he checked the file one fal time. The map had grown a new district overnight — a wide boulevard runng to the edge of the address space, led with trees made of | characters, endg at a gate.

The gate was labeled: exit 0.

$a$

$$
aa
$$
$$\frac{1}{2}$$

1

echo hello

1

print(hello)