Source: https://mayphus.org/systems-storage/
Title: Paths, filesystems and storage devices
Metadata: {"kind":"page","language":"en","route":"/systems-storage/","tags":["learning","systems","storage","linux"],"type":"page"}

# Paths, filesystems and storage devices

[Guide and chapter map](/understanding-computer-systems/) · Prerequisite: [the first observation exercise](/systems-observation/) · Next: [boot and recovery](/systems-hardware-boot/)

## Learning goal

Given a file path, identify which storage question you are asking: where the path resolves, which filesystem contains it, which device or memory backs that filesystem, and whether the data can be recovered after failure. These are related questions with different evidence.

## Four objects that are easy to confuse

A **path** is a name resolved through directories. A **filesystem** supplies directory and file behavior. A **mount point** makes a filesystem accessible at a location in a process's directory tree. A **block device** exposes addressable blocks and may represent a physical disk, a partition, or another storage layer.

Do not infer a one-to-one mapping. A filesystem may span devices, a device may contain several partitions, and an in-memory filesystem may have no ordinary disk underneath it. A container may show a mount view that differs from the host's. The util-linux [`findmnt` manual](https://man7.org/linux/man-pages/man8/findmnt.8.html) explains looking up the filesystem containing a path and choosing explicit output columns; [`lsblk`](https://man7.org/linux/man-pages/man8/lsblk.8.html) serves a different purpose by reporting block devices and their relationships.

This distinction changes diagnosis. “There is space on the disk” does not show that the filesystem containing a particular path has space or that your account may allocate it. “The file is visible” does not show that a copy is on a separate failure domain. A successful write is not a restore test.

## Exercise: ask about one harmless path

**Executed environment:** Ubuntu 26.04.1 LTS, 8 October 2026. These are read-only Linux commands using util-linux `findmnt` and GNU `df`. They require no administrator privileges. The exact mounts and capacities will differ on your machine. Keep real paths and storage details private unless they are necessary to a question.

```bash
findmnt --target /tmp --output TARGET,FSTYPE --noheadings
df --output=fstype,pcent -- /tmp
```

The preparation environment reported `tmpfs` for `/tmp`; `findmnt` returned two matching rows in that environment, and `df` reported `tmpfs` with a current percentage used. The capacity percentage is deliberately not a target to reproduce. The useful observation is the filesystem type, not a claim that every Ubuntu installation places `/tmp` on tmpfs or that this mount listing is a complete physical storage map.

`--target` asks which mounted filesystem contains the named path. Explicit columns keep the exercise narrow. `df` answers a space-accounting question about that filesystem. Neither command creates, formats, mounts, unmounts or resizes storage. An error is a result to investigate with the installed manual; do not respond by running a mount or formatting command.

The [Linux kernel's tmpfs documentation](https://docs.kernel.org/filesystems/tmpfs.html) describes temporary filesystem behavior, including use of memory and possible swap. “Memory-backed” does not mean “immune to resource exhaustion” or “guaranteed never to touch swap.” For a learner, the immediate consequence is simpler: do not store the only copy of something important in an assumed-temporary location.

## A second exercise: draw the evidence, not a guessed disk

Use the output above and the synthetic file from the [first exercise](/systems-observation/) to draw four labels: path, containing filesystem, backing mechanism, persistence tested. The first exercise already removed its file, so no further command is needed.

You can fill in “a generated path under `/tmp`,” “tmpfs in the recorded environment,” and “a temporary filesystem.” The correct last entry is **not tested**. Nothing in the file's line count or the filesystem-type query demonstrated survival across reboot. On another system, keep the backing mechanism unknown until you have evidence.

This is a completed reasoning exercise, not a disk-layout operation. It deliberately ends without writing a partition table, creating a loop device or changing a mount. The separate [Linux disk-layout record](/linux-disk/) illustrates GPT and boot-related regions. It is conceptual context rather than a layout prescription; its marked historical formatting example must not be copied as part of this lesson.

## Redundancy, snapshots and backups answer different questions

A second partition on the same disk still shares that disk's failure. Repeated metadata can help recover a damaged structure without preserving all file contents. A snapshot's recovery value depends on what it covers, where it lives, retention and how it can be restored. Merely listing one is not evidence that an application can be recovered consistently.

For a disposable future lab, define the recovery target before choosing a tool: which file, which version, which destination, which check after restoring it? A production backup plan additionally needs the application's consistency requirements, access controls and an independent copy appropriate to its risks. This chapter performs no backup or restore operation and supplies no claim that an existing system is protected.

## FreeBSD boundary and further reading

Do not translate the Linux commands by changing only a device name. FreeBSD has its own filesystem, GEOM and ZFS administration interfaces. Use the [FreeBSD Handbook's storage chapter](https://docs.freebsd.org/en/books/handbook/disks/) to study those, and the [FreeBSD path in this guide](/systems-freebsd-base/) for a bounded starting point. No FreeBSD storage exercise was executed here.

The useful skill is carrying a precise question between systems while looking up the correct tool for each one. Continue to [boot and recovery](/systems-hardware-boot/) to see why finding a root filesystem is only one stage in starting a machine.