File systems: how storage actually works

Physically, storage (an SSD or a spinning hard disk) is just a large, numbered sequence of fixed-size blocks. There's no built-in concept of a filename, a folder, or "this file belongs to this other file's folder" — all of that is an abstraction the file system builds on top of raw blocks, and it's the file system's entire job to make that abstraction feel natural and reliable.

On most Unix-like file systems, a file's actual identity is an inode — a data structure holding the file's metadata (size, permissions, timestamps, owner) and pointers to the actual data blocks holding its content. Notably, an inode does not store the filename — the name lives in a separate directory entry that simply maps a name to an inode number.

Renaming a file is nearly instant regardless of the file's size, because it's only changing which name points to the same inode — none of the actual data moves. A hard link is a second directory entry pointing to the same inode, meaning two different names genuinely refer to the same underlying data (deleting one name doesn't delete the data until every directory entry pointing to that inode is gone). Copying a file, by contrast, genuinely duplicates the data into new blocks under a new inode — which is why it takes time proportional to the file's actual size.

Deleting a file typically just removes its directory entry and marks its inode (and the blocks it pointed to) as free — the actual bytes on disk are often left physically untouched until something else happens to overwrite that space. This is exactly why file-recovery tools can sometimes restore a "deleted" file — the data may still be sitting there, simply no longer referenced by anything — and why deleting isn't a secure way to destroy genuinely sensitive data without also overwriting it.

Updating a file system's own bookkeeping (which blocks belong to which inode, which blocks are free) takes multiple separate writes. If the power cuts out or the system crashes between two of those writes, the file system's own metadata can end up in an inconsistent state. A journaling file system writes a short log entry describing an intended change before making it; if a crash happens mid-operation, the journal lets the file system replay or cleanly roll back the incomplete change on the next boot, instead of leaving structural corruption behind. Most modern file systems (ext4, NTFS, APFS) journal for exactly this reason.

A single machine can have multiple separate file systems (a main disk, a USB drive, a network share) — mounting is the operation that attaches one of these onto a specific point in the overall directory tree, making it appear as an ordinary subfolder even though the data underneath may live on completely different physical media, or even a different machine over the network.