File systems¶

Exercise file-systems-annex.pdf · PDF

You try to copy a 5 GB film to a 64 GB USB stick. The stick is almost empty. Windows answers: "The file is too large for the destination file system." Sixty gigabytes free, and a five-gigabyte file does not fit. How?

The answer is not the size of the stick. It is the file system on it — the invisible organisation that every disk, stick and SD card needs before it can hold a single file. Your three new partitions on deb-lab have walls, but nothing inside. Today you give them one each, and learn to choose.

Rooms with no shelves¶

Look at the second disk from Partitions: MBR and GPT:

lsblk -f /dev/vdb

Three partitions — dev, design, exchange — and the columns FSTYPE, LABEL and UUID are empty. Three rooms of the pantry: walls and a door, nothing inside. Where would you put the first jar? How would you find it tomorrow?

A file system is the organisation written on top of a partition that turns a long row of numbered blocks into named files and folders.

A partition is just blocks, usually 4 KiB each. The file system has four jobs:

The inode¶

An inode is the record (the card) a file system keeps for each file: everything about the file except its name.

The command stat prints a file's inode number, for example Inode: 26192. That number is the card. The name lives in the directory, next to the inode number. So renaming a file never moves a single byte of data — only the sign on the shelf changes.

Be the file system¶

Here is a tiny disk of 16 blocks, numbered 0 to 15. You are its file system. Each new file goes into the first free blocks. Six orders:

1. Save A (2 blocks) · 2. Save B (3) · 3. Save C (4) · 4. Save D (2) · 5. Delete B · 6. Save E (4)

After order 4, the disk looks like this (the inventory would say: A 0–1, B 2–4, C 5–8, D 9–10):

Deleting B frees blocks 2, 3 and 4. Then E needs 4 blocks: it takes the first free ones, 2, 3 and 4, and then 11.

The Exercise sheet has its own six orders for you to play by hand, with a pencil.

Three lessons hide in that little table:

• E is in two pieces. That is fragmentation. On a hard disk the arm must jump between pieces (a seek, about 10 ms, from Storage); on an SSD it hardly matters.
• When B was deleted, its blocks were not rubbed out. A real file system only crosses out the card and marks the blocks free. The bytes stay until something is written over them (an SSD may clear them sooner). That is why deleted files can sometimes be recovered.
• Now hide the inventory. Only the disk is visible. Which blocks belong to C? Nobody can say. That is exactly what formatting does.

The journal¶

Saving one file means several writes: the data blocks, the inode, the free list, the directory. Imagine the power goes out between the second and the third. What does the inventory say now? It lies.

A journal is a small notebook where the file system first writes what it is about to do, and only then does it.

After a power cut, the file system reads the notebook and finishes or undoes the half-done job in seconds. Without a journal, the whole disk has to be checked.

Six file systems¶

You already know two: NTFS from Windows Disk Management, and ext4, which df showed on your own deb-lab.

Back to the film from the top of the page: the stick is FAT32. Its limit is per file, not per disk. A 5 GB file is over 4 GiB, so it cannot be stored, however much free space there is.

Format the three partitions¶

mkfs (make file system) writes a new file system on a partition. There is one program per type: mkfs.ext4, mkfs.xfs, mkfs.exfat. The option -L gives the file system a label.

mkfs.ext4 comes with Debian; the other two need their tools first:

student@deb-lab:~$ sudo apt install xfsprogs exfatprogs
student@deb-lab:~$ sudo mkfs.ext4 -L dev /dev/vdb1
mke2fs 1.47.2 (1-Jan-2025)
Creating filesystem with 524032 4k blocks and 131072 inodes
Filesystem UUID: f8a95ce9-8b9c-4c25-8456-bbe0d679773d
Creating journal (8192 blocks): done
student@deb-lab:~$ sudo mkfs.xfs -L design /dev/vdb2
student@deb-lab:~$ sudo mkfs.exfat -L EXCHANGE /dev/vdb3
exFAT format complete!

(The mkfs.ext4 output is shortened.) Read its lines: 524,032 blocks of 4 KiB fill the 2 GiB room; 131,072 inodes means at most that many files; and a journal was created.

student@deb-lab:~$ lsblk -f /dev/vdb
NAME   FSTYPE FSVER LABEL    UUID
vdb
├─vdb1 ext4   1.0   dev      f8a95ce9-8b9c-4c25-8456-bbe0d679773d
├─vdb2 xfs          design   bbcb8ec8-342d-41ea-9c50-a656a11c52ed
└─vdb3 exfat  1.0   EXCHANGE 7AF7-138C

A UUID (Universally Unique Identifier) is a random identifier written into a file system when it is created. Every file system gets its own.

Your UUIDs will be different from these. If a line looks empty just after formatting, run lsblk -f again: the list refreshes a moment later.

Look inside, format again¶

tune2fs -l prints the details of an ext4 file system. Pipe it into grep (from Finding information) to pick one line:

sudo tune2fs -l /dev/vdb1 | grep "Block size"
sudo tune2fs -l /dev/vdb1 | grep "Inode count"
sudo tune2fs -l /dev/vdb1 | grep has_journal

The answers: 4096 bytes per block, 131072 inodes, and a long line of features that contains has_journal.

Now format vdb3 again with the same mkfs.exfat command, and run lsblk -f: the UUID of vdb3 is new. A new, empty inventory was written. Try the same with XFS:

student@deb-lab:~$ sudo mkfs.xfs -L design /dev/vdb2
mkfs.xfs: /dev/vdb2 appears to contain an existing filesystem (xfs).
mkfs.xfs: Use the -f option to force overwrite.

mkfs.xfs refuses; mkfs.exfat did not say a word. Never count on the tool to stop you.

Finally, blkid shows both names a partition now has:

student@deb-lab:~$ sudo blkid /dev/vdb1
/dev/vdb1: LABEL="dev" UUID="..." BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="dev" ...

PARTLABEL is the partition's name, set by parted. LABEL is the file system's name, set by mkfs. Two different layers, two different names.

How to choose¶

There is no "best" file system. Ask three questions, in this order:

flowchart TB
    Q1{"<b>Who must read it?</b>"}
    Q1 -->|"only Windows"| NTFS["<b>NTFS</b>"]
    Q1 -->|"several systems,<br>or a device: camera, TV, car"| DEV{"<b>Is the device old,<br>or does it say FAT?</b>"}
    DEV -->|"no"| EXFAT["<b>exFAT</b>"]
    DEV -->|"yes"| FAT["<b>FAT32</b>"]
    Q1 -->|"only Linux"| Q2{"<b>Anything special?</b>"}
    Q2 -->|"no"| EXT4["<b>ext4</b><br>the safe default"]
    Q2 -->|"huge files on a server<br>that only grows"| XFS["<b>XFS</b>"]
    Q2 -->|"snapshots to go<br>back in time"| BTRFS["<b>Btrfs</b>"]

The third question: is it the system disk? Then the operating system decides: Windows needs NTFS; the Debian installer proposes ext4.

The Exercise sheet ends with six cases at Tramuntana Apps — Marta's workstation, Aina's laptop, Joan's project disk, a camera card, an old TV, a video archive — to decide in pairs, with one reason each.

Key takeaways¶

• A file system turns a partition's blocks into files: names, the map of blocks (inodes), free space, and data about each file.
• The inode holds everything about a file except its name; the name lives in the directory.
• A quick format writes a new, empty inventory; the old bytes stay, orphaned. Deleting a file only crosses out its card.
• A journal keeps the inventory consistent after a power cut. It is not a backup.
• ext4 Linux default · XFS big servers, cannot shrink · Btrfs snapshots · NTFS Windows · FAT32 everything reads it, 4 GiB per file · exFAT sticks and cards, no 4 GiB limit.
• mkfs.TYPE -L LABEL /dev/PARTITION creates one; lsblk -f and blkid show type, label and UUID.

Quick check¶

Your three rooms have shelves and an inventory now. Try to save a file in dev: cd /dev/vdb1 answers Not a directory. The file system exists, but it hangs nowhere in the tree. Next: Mounting file systems.