We closed module 3 with an uncomfortable admission: for three modules we had been writing /var/lib/meteora/readings/2026-08-31.dat as if that string of text were something self-evident, when in module 2 we left storage in a very different place. There, an NVMe SSD was a vector of blocks numbered 0 to N, addressable by LBA, with no names, no folders, no sizes and no owners. A giant array of 512 or 4,096 bytes per slot. Nothing more.

Between that vector of blocks and the path /var/lib/meteora/readings/2026-08-31.dat sits one of the most successful abstractions in computing: the file system. It is the piece that turns "block 8,394,271" into "yesterday's readings file", that remembers who created it and when, that knows it takes up 17 MB spread over thousands of scattered blocks, and that lets a C program read it without knowing anything at all about LBAs, sectors or geometry.

This lesson builds that abstraction from the ground up. We are going to define precisely what a file is, see what metadata it carries and where that metadata lives, dissect the inode — the central structure of every UNIX system — walk through the physical layout of a file system on the device, calculate why the block size is a trade-off and not an accident, and finish by comparing the families of file systems that exist so we can decide, with arguments, which one deserves /var/lib/meteora.

1. From the raw block to the file: what problem the abstraction solves
2. What a file is: content, metadata and name
3. The seven UNIX file types
4. ls -l and stat interpreted field by field
5. The inode: what it contains and what it does not
6. Inode numbers, ls -i and exhaustion with df -i
7. Physical layout of a file system on the device
8. Block size and its trade-off, calculated
9. Timestamps: atime, mtime, ctime, crtime and the reason for noatime
10. Families of file systems compared
11. Meteora's decision for /var/lib/meteora

Imagine for a moment that Meteora had no file system and worked directly on /dev/nvme0n1, the block device from module 2. The ingestor would have to solve, all by itself, this list of problems:

Every program on the server would have to solve all seven, each one its own way, and none could cooperate with the others. It is exactly the situation we described in 01-01 when we talked about the operating system as an extended machine: without it, every application reimplements the hardware.

The file system solves all seven at once with a single idea:

A file is a named sequence of bytes, with a size and an owner, that the system stores wherever it likes and the program reads as if it were continuous.

The four key phrases in that definition deserve attention:

• Sequence of bytes. In UNIX a file has no internal structure known to the system. There are no "records", no "fields", no types. That 2026-08-31.dat contains 720,000 24-byte Reading structs is an agreement among Meteora's own programs, invisible to the kernel. Other historical systems (IBM's, VMS) did impose a record structure, and the industry eventually decided UNIX's flat model was right, because of its simplicity.
• Named. The name is the handle by which the user grabs the file. In section 5 we will see the surprise: the name is not inside the file.
• Wherever it likes. The system decides which blocks to use. That is what we will study in Space Allocation, Journaling and Integrity.
• As if it were continuous. This is the magic. 2026-08-31.dat occupies 4,219 blocks that may be scattered all over the SSD, and yet read() delivers them in order as a stream of bytes. It is the same class of illusion as the virtual memory of module 2: contiguous logical addresses over scattered physical storage.

In fact the parallel with virtual memory is so exact that it is worth pinning down, because it will save you effort throughout the module:

It is the same idea applied twice: a translation table that turns an orderly logical space into a disorderly physical one.

A file has three parts, and they live in three different places. This separation is the key to everything else:

• The content: the bytes themselves, in the device's data area.
• The metadata: everything the system knows about the file. It lives in the inode.
• The name: it lives in the directory that contains it, not in the file. We will develop this in Directory Structures, but you need to know it already to understand the inode.

A file's typical metadata, with what each item means:

Notice something you can already sense: the name does not appear in that list. It is not an oversight; it is UNIX's central design decision, and out of it come hard links, deferred deletion and half a dozen behaviors that are surprising until you understand this.

In UNIX, the phrase "everything is a file" is meant seriously. The same interface — open, read, write, close — works for a data file, a keyboard, a pipe or a network connection. What changes is the type, a 4-bit field in the inode:

The last three are old friends from module 3: we used the FIFO at /run/meteora/readings.fifo in Inter-Process Communication (IPC), and UNIX domain sockets too. The difference is that there we saw them as IPC mechanisms and here we see them as file system entries: they have an inode, permissions and a name, but their content is not on disk — a FIFO has a buffer in kernel memory, a socket has a network queue. They take up one inode and zero data blocks.

The same goes for block and character devices, which we saw in Device Management: their inode holds no data pointers, it holds the (major number, minor number) pair that identifies the driver. A device file is, literally, an inode with a couple of integers inside.

Let us really look at it. This is the listing of Meteora's directory on meteo-01:

The fields, from left to right:

1. First character: the type from the previous table. -, l, d, b, c, p, s. At a glance you already know what each thing is.
2. The next nine characters: the permissions, which we will look at in File Security and Permissions.
3. The number after the permissions: the link count. It is 1 for ordinary files and 2 for the archive directory (04-02 explains why).
4. Owning user and group: meteora meteora.
5. Size: 17,280,000 bytes for the readings. But look at /dev/nvme0n1: where the size ought to be it says 259, 0. Those are the major and the minor. A device file has no size because it has no content; in its place ls shows the pair that identifies the driver. And the FIFO and the socket show 0, for the same reason.
6. Date: by default the mtime, not the creation time nor the last access time (section 9).
7. Name, with the -> target on the symbolic link.

ls -l is a summary. To see everything you use stat:

Field by field, with what you need to understand about each one:

• Size: 17280000. The file's logical bytes: exactly 720,000 readings × 24 bytes. It is the number lseek(fd, 0, SEEK_END) returns.
• Blocks: 33760. Here is a classic trap: stat counts 512-byte blocks, always, regardless of the file system's real block size. 33,760 × 512 = 17,285,120 bytes occupied on disk, somewhat more than the 17,280,000 logical ones. The difference is 5,120 bytes: 4 KiB for the partially used last block plus the metadata of the extent tree. When "blocks × 512" is smaller than the size, that is the signature of a sparse file (we will see it in 04-04).
• IO Block: 4096. The preferred block size for reads; reading in multiples of this number saves the kernel extra work.
• Device: 9,0. Major 9, minor 0: /dev/md0, the RAID 1 we assembled in 02-05. This pair identifies which file system the inode lives in, and the (device, inode) pair is the only thing that uniquely identifies a file across the whole machine.
• Inode: 1180934. The inode number. Section 6 is devoted to it.
• Links: 1. A single name points to this inode (04-02).
• Access (0640). Twelve mode bits, shown in octal and symbolically (04-06).
• Uid/Gid 990. The meteora user and group. Careful: the inode stores numbers, not names; the translation into meteora is done by stat consulting /etc/passwd.
• The four dates: section 9.

The inode (index node) is the data structure that is the file. Everything else is a reference to it. It lives on disk, in a reserved area, and has a fixed size: 256 bytes on a modern ext4 (128 on old ones, configurable at format time).

Its contents, grouped:

And now the important part, which is what is not there:

The file's name is not in the inode. Neither is the path, nor the directory it belongs to, nor anything relating it to /var/lib/meteora/readings/2026-08-31.dat.

Inode 1180934 does not know what it is called. It knows it is a regular file of 17,280,000 bytes belonging to UID 990, that there is 1 name somewhere pointing at it, and which blocks hold its data. Nothing else.

This is not a limitation: it is the design decision half this module hangs from. Its consequences, which we will unfold as we go:

Keep this sentence: the inode is the file; the name is just a label stuck on from outside.

Every inode has a unique number within its file system. You can see it with ls -i:

Two files in the same file system with the same inode number are the same file. Two files in different file systems may share a number without having anything to do with each other: that is why the real identity is the (device, inode) pair, st_dev + st_ino in stat. It is exactly what find -samefile checks and what rsync uses so it does not copy the same linked content twice.

Now the practical part. In ext4, the number of inodes is fixed at format time and cannot be increased afterwards. They are reserved in advance, with a default ratio of one inode per 16 KiB of capacity:

Interpretation: the volume has 13,107,200 inodes (200 GiB ÷ 16 KiB) and uses only 1,834, because Meteora stores one large file per day and has been running for about five years. With that policy, in 100 years it would use 36,500 inodes: 0.28 %.

The other way round, however, produces the most bewildering failure in systems administration:

"No space left on device" with 36 GB free. The error is ENOSPC and it is literal from the kernel's point of view: there is no inode space left. A process that creates millions of tiny files — caches, sessions, mail queues — exhausts the inode reserve long before the blocks. Diagnostic rule: faced with an ENOSPC, always run both df -h and df -i; if the first explains nothing, the second will.

To find the culprit:

The command counts files per directory: -xdev avoids crossing into other file systems, -printf '%h\n' prints each file's directory, and sort | uniq -c | sort -rn groups and sorts. Almost three million files in sessions: there is the problem.

The fix is not to enlarge the disk, because inodes do not grow: you have to delete files or reformat with mkfs.ext4 -i 4096 (one inode per 4 KiB, four times as many) or -N 8000000 (an explicit number). This is one of the arguments in favor of XFS and Btrfs, which allocate inodes dynamically and do not suffer from this problem.

We now know what an inode is. Where is it physically? Let us open the device up. The hierarchy of units, from smallest to largest:

The sector is the smallest unit the device knows how to read or write; we saw it in 02-05. The logical block is the smallest unit the file system knows how to allocate: even though the disk can read 512 bytes, ext4 never allocates less than one block to a file.

An ext4 is divided into block groups of 128 MiB, each with its own accounting. The reason is performance and comes straight out of module 2: keeping together the metadata and the data that are used together reduces head movement on an HDD and improves locality on an SSD.

Piece by piece:

The superblock. It is the file system's identity card, and it takes up a single block. It contains the total number of inodes and blocks, how many are free, the block size, the inode size, the number of blocks per group, the UUID, the label, the date of the last mount, the mount counter and the state (clean or dirty, which will be decisive in 04-05). Without a superblock nothing can be mounted, because you do not even know where the inodes begin. That is why ext4 keeps backup copies in several groups:

If the primary one is corrupted, you recover with sudo e2fsck -b 32768 /dev/md0, which tells e2fsck to use the backup at block 32768. It is a command worth writing down: it saves volumes that looked lost.

The group descriptors. An array with one entry per group, saying where that group's bitmaps and inode table are and how many free elements it has. It is the index that lets you find everything else.

The block bitmap. One bit per block in the group: 1 = used, 0 = free. With 4 KiB blocks, a 128 MiB group has 32,768 blocks, which is 32,768 bits = 4,096 bytes: exactly one block. That is no coincidence; the group size is chosen precisely so that its bitmap fits in one block.

The inode bitmap. The same thing for the group's inodes.

The inode table. The array of inodes proper. If a group has 8,192 inodes of 256 bytes, it takes up 2 MiB = 512 blocks. This is where an inode's position is computed from its number, with pure arithmetic and without searching any index:

Two divisions and one multiplication: that is all it costs to go from an inode number to its position on disk. Inodes are numbered from 1, hence the - 1. This is the deep reason why an inode is a number and not a name: looking up a name would require walking a table; a number is resolved with arithmetic in nanoseconds.

The data area. Everything else: the blocks holding the files' bytes.

You can see it on your own machine with dumpe2fs:

Every line is a real superblock field. Block count: 52428800 × 4,096 = 200 GiB. Filesystem state: clean means it was unmounted properly. And dir_index and extent are features that will show up in 04-02 and 04-05.

The block size is chosen at format time and cannot be changed afterwards. It is a genuine trade-off, and it shows up in the numbers.

The cost of a large block: internal fragmentation. Since allocation happens in whole blocks, each file's last block is left partially empty, and that space is lost. On average half a block per file is wasted.

The cost of a small block: more blocks to manage. More entries in the metadata, more allocation work, and smaller I/O requests.

With Meteora's real files (17,280,000 bytes):

For 17 MB files the waste is irrelevant in every case: 21 KB out of 17 MB is 0.12 %. But the number of blocks to manage changes by a factor of 64.

Now the opposite scenario, a directory with a million 800-byte files (sessions, not readings):

With 64 KiB blocks, a million 800-byte files would occupy 64 GB to store 800 MB. The very same block size that was irrelevant for the readings is catastrophic here.

Why 4 KiB is the universal standard, and not an arbitrary convention:

1. It matches the page size (module 2). The kernel's page cache works in 4 KiB pages; if the block is the same size, one block = one page and nothing has to be split or joined. A block larger than the page cannot be mapped directly with mmap(), which is precisely what the aggregator does with 2026-08-31.dat (02-04). In fact, Linux does not support blocks larger than the page size, so on x86-64 the maximum is 4 KiB.
2. It matches the physical sector of modern disks (Advanced Format, 4Kn), so no write triggers the read-modify-write cycle.
3. It balances the waste for the real distribution of file sizes on a typical system.

Practical rule: use 4 KiB unless you have a measured reason not to. The reason to go down to 1 KiB is a volume dedicated to millions of tiny files; to go up you would have to move to XFS on architectures with larger pages, or to file systems with bigalloc.

Four dates, and three of them get confused constantly:

The most frequent mistake is believing that ctime is creation time. It is not: it is change time, the moment any piece of metadata changed. Changing the permissions with chmod, the owner with chown or creating a hard link modifies the ctime but not the mtime, because the content has not changed. And since it cannot be set backwards (not even touch -d touches it), the ctime is the timestamp a forensic analyst looks at: whoever tampers with a file can fake atime and mtime, but in doing so they update the ctime, giving themselves away. We will come back to it in module 5.

A table of what each operation touches on 2026-08-31.dat:

¹ Renaming changes the directory, not the file's inode. ² It changes the link count, which is in the inode.

Here is the practical problem. Updating the atime means writing to disk when you read a file. It sounds absurd, and it is: it turns a read-only operation into a read-and-write one.

The numbers for Meteora. meteo-api serves about 2,000 queries an hour, each one reading the day's file. With strict atime, that is 2,000 writes an hour to the inode of a file nobody has modified: 48,000 daily metadata writes, plus their corresponding journal entry (04-05), on a RAID 1 where every write goes to both disks. And on an SSD, write cycles spent for nothing.

The available mount options, which we will apply in Partitions, Mounting and the Virtual File System:

relatime is the compromise Linux adopted: it preserves the semantics needed by tools that ask "has this been read since it was last modified?" (mail clients, above all) at a fraction of the cost. noatime removes it altogether.

Meteora mounts /var/lib/meteora with noatime, because no program on the system consults the readings' atime and the saving is real. The general rule: on a server data volume, noatime is almost always right; on a user volume with old mail clients, stay with relatime.

There are dozens. These are the ones you will actually run into, with what really distinguishes them:

Four observations worth more than the whole table:

FAT32 and the 4 GiB limit. It is the real limit most people run into at some point in their lives: copying a 5 GB video to a USB stick fails, and not for lack of space. FAT32 stores the size in 32 bits, so 2³² − 1 = 4,294,967,295 bytes is the absolute ceiling. And it has no journal: a power cut in the middle of a write can leave it inconsistent with no automatic way to repair it. It survives because absolutely everything reads it, including your motherboard's UEFI, which requires a FAT32 partition in order to boot.

tmpfs is not a disk. It lives in the page cache and in swap: blazingly fast and volatile. It is what sits behind /dev/shm/meteora-cache (03-03) and /run/meteora/. That Meteora's cache "is a file" and at the same time lives in RAM is not a contradiction: it is a file in a file system with no device behind it. We will look at it in detail in 04-03.

Copy-on-write versus journal. They are two different philosophies for the same problem — surviving a power cut. The journal writes down what it is about to do before doing it; copy-on-write never overwrites a live block, it writes a new copy and switches the pointer at the end. That is the subject of Space Allocation, Journaling and Integrity.

Data checksums. Only Btrfs and ZFS verify that the data they return is what was written. ext4 and XFS verify their metadata and their journal, but if a bit of your readings gets corrupted on the platter, they hand it to you corrupted without warning. That is silent corruption, and it also belongs to 04-05.

With all of the above, the choice can now be argued rather than copied from a tutorial. Meteora's workload profile:

The candidates and their reasoned rejection:

Decision: ext4, with this justification:

1. Maturity and predictability. It is the file system with the most flight hours in the Linux ecosystem. For unrecoverable data, "boring and proven" is worth more than "modern and promising".
2. Extents. A contiguous 17 MB file is described with a single extent instead of 4,219 pointers. We will measure it with filefrag in 04-05.
3. Tooling. dumpe2fs, debugfs, tune2fs, e2fsck and resize2fs (which can shrink, unlike XFS) make up the most complete set. When something goes wrong at three in the morning, that counts.
4. The journal in ordered mode guarantees that another file's data will never appear inside the readings after a failure. We will justify it in 04-05.
5. Inodes are not an issue for this workload: 1,834 used out of 13 million.
6. The lack of data checksums is compensated for by other means: md verifies the RAID 1 with a weekly scrub, and the ingestor stores a CRC32 per reading in its own format.

The exact formatting parameters:

What each option does and why here:

• -b 4096: it matches the page and the NVMe's physical sector; it also allows direct mmap().
• -i 1048576: by default there would be 13 million inodes, of which 1,834 are used; with one inode per MiB there are 200,000 left, more than enough, and it saves about 3 GiB of inode table that becomes usable space. It is a safe adjustment only because we know the workload.
• -m 1: ext4 reserves 5 % for root, so that a full disk does not prevent logging in or operating. On a 200 GiB data volume that means 10 GiB tied up; at 1 % it is 2 GiB, margin enough. Careful: on / never go below 5 %.
• -O extent: extents instead of indirect pointers (04-05).
• -O dir_index: hash indexes for large directories (04-02).
• -O metadata_csum: metadata checksums, which detect corruption of the inode or the bitmap.

And that is how /var/lib/meteora/readings/2026-08-31.dat stops being a magic string and becomes inode 1180934 of the ext4 labeled meteora-data on /dev/md0.

Believing that ctime is the creation date. It is change time: it changes with chmod, chown or when a hard link is created. The real creation time is the crtime, which only stat shows on modern systems. Confusing them leads to false conclusions in any forensic analysis.

Misreading stat's Blocks field. They are always 512-byte blocks, even if the file system uses 4 KiB. If you multiply by 4,096 you will get a size eight times larger than the real one.

Not looking at df -i when faced with an ENOSPC. A disk at 26 % that reports "No space left on device" is almost always inode exhaustion. Always check both.

Assuming the number of inodes can be increased. In ext4 it is fixed at format time and there is no going back. If you foresee millions of small files, decide -i beforehand, or use XFS or Btrfs, which allocate them dynamically.

Choosing a large block "because it is faster". With a million 800-byte files, a 64 KiB block wastes 99 % of the space. The block size depends on the distribution of your files' sizes, not on an intuition about speed. And on Linux it cannot exceed the page's 4 KiB.

Running mkfs on the wrong partition. mkfs does not ask. Always confirm with lsblk and blkid before pressing Enter; we will see this in 04-03.

Tip: save the dumpe2fs -h output of your volumes. Having the UUID, the block size and the positions of the backup superblocks at hand turns an emergency recovery into a two-minute formality.

Tip: use stat instead of ls -l when something does not add up. It shows the four dates, the inode, the device and the real blocks. Half the mysteries involving files are solved by reading a stat calmly.

Tip: check the type before assuming. Before running cat on something unknown, look at the first character of ls -l. A cat on a 200 GiB block device, or on a FIFO with no writer, does not end the way you expect.

Without using ls -l, write a command that classifies everything in /dev, /run and your home directory by file type, counting how many there are of each. Then take a regular file of at least 10 MB, run stat on it, and answer: (a) how many 4 KiB blocks does it actually occupy? (b) how much space is wasted in the last block? (c) do mtime and ctime match, and what does it mean if they do or do not?

A 500 GiB volume is going to host one of two possible workloads. Workload A: Meteora's daily files, 17,280,000 bytes each, for 30 years. Workload B: 20 million 600-byte session files. For block sizes of 1, 4 and 64 KiB, calculate for each workload: total blocks needed, space actually occupied, absolute waste and percentage. Then state which size you would choose for each workload and whether a single volume can serve both.

A colleague warns you: the session service on meteo-01 is failing with "No space left on device", but df -h shows the volume at 31 %. Write the complete diagnostic procedure — which commands you run, in what order and what you expect to see in each one — the technical explanation of why it happens, the immediate fix to restore the service and the definitive fix so it does not happen again. Include the formatting command you would use and justify its parameters.

Solution 1

Classifying by type is done with find -type or, better, with stat's format:

-printf '%y' prints a single letter with the type (f regular, d directory, l link, b, c, p, s), and sort | uniq -c counts them. Typical output:

For the questions, with a stat giving Size: 17280000 and Blocks: 33760:

(a) stat counts 512 B blocks: 33,760 × 512 = 17,285,120 bytes. In 4 KiB blocks that is 17,285,120 / 4,096 = 4,220 blocks. The data needs ⌈17,280,000 / 4,096⌉ = 4,219, so the extra block is extent tree metadata.

(b) 17,280,000 = 4,218 complete blocks + 3,072 bytes. The last block uses 3,072 out of 4,096, so 1,024 bytes are wasted: 0.006 % of the file. Irrelevant here, decisive with 800-byte files.

(c) If mtime and ctime match, the last operation was a content write (which updates both). If the ctime is later, some piece of metadata was modified after the write: a chmod, a chown or an ln. A ctime later than the mtime with no known cause is exactly what makes an analyst suspicious.

Solution 2

Workload A — one file of 17,280,000 B, 30 years × 365 = 10,950 files:

Over 189 GB of data, even 235 MB is 0.12 %. With 4 KiB, the waste is 0.006 %: negligible. What rules here is the number of blocks to manage, and 4,219 is far easier to handle than 16,875.

Workload B — 20,000,000 files of 600 B (12 GB of real data):

With 64 KiB it does not fit: it would take 1.3 TB on a 500 GiB volume to store 12 GB of data.

Choice. Workload A: 4 KiB, for its affinity with the page and mmap(), with effectively zero waste. Workload B: 1 KiB, which saves 61 GB compared with 4 KiB. And an important warning for workload B: 20 million files need 20 million inodes, and the default mkfs would give 32.7 million — only just — so you have to set -i 2048 or use XFS.

A single volume for both? Technically yes, but it is a bad idea: the requirements are opposites (large block and few inodes versus small block and many inodes), and besides, mixing workloads means the millions of small files fragment the space the large ones need. Two separate volumes, which is exactly the partitioning argument we will see in 04-03.

Solution 3

Diagnostic procedure, in order:

Step 2 is the diagnosis and step 4 identifies the culprit. -xdev matters: without it, find would cross into other file systems and count files that do not consume this volume's inodes.

Technical explanation. In ext4 the number of inodes is fixed and decided at format time, with one inode per 16 KiB by default. A 50 GiB volume therefore has 3,276,800 inodes. Every file, however small, consumes one. When they run out, creat() and open(O_CREAT) return ENOSPC — "No space left on device" — even though free blocks remain, because the kernel does not distinguish between the two resources in the error code. The 600-byte session files take one 4 KiB block and one inode each: the inodes run out once you reach 3.2 million, with only 13 GB used.

Immediate fix (restore the service):

Deleting files older than 7 days frees inodes immediately. With millions of files it is better to use find ... -delete instead of rm -rf, which can overflow the command line.

Definitive fix, in three layers:

1. Automatic purge: a systemd unit with a timer (module 7) or a tmpfiles.d entry that deletes expired sessions every hour.
2. Reformat with the right density, after taking a backup:

-b 1024 because the files are 600 bytes and with 4 KiB you waste 85 %; -i 2048 gives one inode per 2 KiB, that is 26 million inodes, far above the original 3.2; -m 0 because it is a temporary data volume where no root reserve is needed.

3. Monitoring: alert when df -i goes above 80 %, exactly the way space is watched. Almost no monitoring system does it by default, and that is why this failure keeps showing up.

A reasonable alternative: mount /var/spool/cache as tmpfs, since sessions are volatile by nature. Both problems disappear at once, at the cost of RAM and of losing them on reboot (04-03).

A file is a named sequence of bytes, with a size and an owner, that the system places wherever it likes and the program reads as if it were continuous. That abstraction solves in one stroke the seven problems any application would face working on module 2's raw block vector, and it does so with the same strategy as virtual memory: a translation table that turns an orderly logical space into a scattered physical one.

A file has three parts in three places: the content in the data area, the metadata in the inode, and the name in the directory. The central consequence, from which half this module hangs, is that the name is not inside the file: inode 1180934 does not know it is called 2026-08-31.dat.

In UNIX there are seven types of file — regular, directory, symbolic link, block device, character device, FIFO and socket — and the last four take up an inode but zero data blocks: the FIFO /run/meteora/readings.fifo and the api.sock socket from module 3 are file system entries whose content lives in the kernel. ls -l tells them apart by their first character and stat reports everything: logical size, 512-byte blocks, device, inode, link count and the four dates.

Physically, an ext4 is divided into block groups of 128 MiB, each with a block bitmap, an inode bitmap, an inode table and a data area, preceded by the superblock — the identity card, with backup copies that save volumes — and the group descriptors. Going from an inode number to its position on disk costs two divisions and one multiplication, and that is the deep reason why the inode is a number.

The block size is a measurable trade-off: 4 KiB is the standard because it matches the memory page (and therefore the page cache and mmap()) and the modern physical sector; going lower makes sense with millions of tiny files, and going higher is not even possible on Linux. Inodes, in ext4, are fixed at format time: hence the ENOSPC with a half-empty disk that only df -i explains. And the four timestamps distinguish reading (atime), modifying content (mtime), modifying metadata (ctime) and creating (crtime); noatime removes 48,000 useless daily writes on meteo-01.

With the comparison of families in hand, Meteora chooses ext4 for /var/lib/meteora: maturity in the face of unrecoverable data, extents to describe 17 MB in a single run, the most complete toolset for three in the morning, and a deliberate tuning of -i 1048576 and -m 1 that recovers about 11 GiB for useful data.

We are left with the loose end we have been dropping in every section: the name. We know it is not in the inode, we know it lives "in the directory", and we have said that a directory is "a special file", but we have not opened one. What exactly is inside /var/lib/meteora/readings/? How does the system manage to turn the string /var/lib/meteora/readings/2026-08-31.dat into the number 1180934, and how many disk accesses does that cost? Why can a symbolic link end up broken and a hard one cannot? And what happens when a directory has a hundred thousand files inside it?

All of that is what the next lesson opens: Directory Structures.